Re[2]: Императивное программирование
От: AlexRK  
Дата: 20.09.12 17:45
Оценка: +5 -1
Здравствуйте, Гест, Вы писали:

Г>Покажите школьнику


Код на паскале читается проще, несмотря на больший объем. Считай, программа последовательно и читается, как есть. Что написано, то и происходит.
А код на руби школьник — даже если и угадал, что программа делает — я думаю не понял.

Г>Я — показывал.


Ну, реакция одного школьника, какой бы она ни была, ничего не доказывает и не опровергает.
Re[5]: Императивное программирование
От: Гест Украина https://zverok.github.io
Дата: 20.09.12 18:34
Оценка: -1 :)))
Ох. Простите ради бога, я не готов общаться на таком накале инженерного мышления.
Re[3]: Императивное программирование
От: Философ Ад http://vk.com/id10256428
Дата: 20.09.12 21:56
Оценка: +1 -2 :)
Python ужасен.
Руби я никогда раньше не видел, но код на руби мне понравился сразу, а в код на питоне я некоторое время фтыкал...
Всё сказанное выше — личное мнение, если не указано обратное.
Re[83]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.10.12 11:09
Оценка: +2 :))
Здравствуйте, Ikemefula, Вы писали:

I>Ты внятно ответь на вопрос — где я предлагаю использовать С++ для обучения ? Есть простой факт — С++ крайне востребован в определенных областях, котрые крайне актуальны.

Это не делает его идеальным языком для обучения программированию. И даже идеальным языком для программирования вообще.
I>Представляю. SQL обычно используется чисто для выборки даннх и предварительной обработки. Основной процессинг всегда на сервере. Например потому, что для процессинга нужны данные из разных источников или же нужны все данные и сразу.
Простите, но настоящего SQL вы никогда не видели. "Основной процессинг". "Чисто для выборки данных". Не смешите меня, пожалуйста.
Даже если не пользоваться group by с having и подзапросами, а только джойнами, where и order by, то вы употеете делать аналогичную "чисто выборку данных" на императивном языке. А обеспечение ACID для типичной OLTP-транзакции вам будет стоить седых волос в неожиданных местах.

I>В чем то ты прав, когда винда зависает от того, что лоток привода закрывается, то часто это означает, что драйвер писал программист который считал что драйверу скорость не нужна.

Вообще-то нет. Как правило, это означает, что драйвер писал программист, считающий скорость важнее корректности.
Чтобы понять, что вы пишете чушь, нужно представлять скорости современного железа. За время "закрытия лотка" процессор успевает намолотить столько, что заметных задержек в UI не даст даже JavaScript, интерпретируемый интерпретатором, написанным на SQL.
Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать мало-мальски интересных инвариантов.
I>Вот оконному манагеру скорость точно не нужна, ибо он не занимается низкоуровневыми вещами, а они, в свою очередь, написаны на мега-оптимизированом инструменте.
Скорость и низкоуровневость связаны между собой вовсе не так, как вы полагаете — если судить вот по этому бредовому утверждению.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.12 15:14
Оценка: 27 (2) -1
Здравствуйте, Ikemefula, Вы писали:
>>Попробуйте расшифровать, как советует нам поступить в той или иной ситуации пословица "не всякий цветок даёт плод".
I>А что, модальности уже отменили ? Не знал.
I>"не всякий цветок даёт плод" -> "не стоит ждать плода от каждого цветка"
Отлично. Ничего, что это две разные фразы? Или вы считаете их семантически неразличимыми?
I>Это заблуждение. Если ты внимательно читал ссылки, то там вобщем легко понять что твоя фраза императивна до безобразия
I>"собака лает", "машина едет", "корован грабят" — императивны.
Отлично. Таким образом, мы выяснили, что неимперативных утверждений не бывает.
Вот, например, известное соотношение grad div rot x == 0 надо трактовать как инструкцию "не стоит ждать ненулевых значений от градиента дивергенции ротора любого векторного поля".
Или можно привести в студию пример "неимперативной" фразы?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Императивное программирование
От: Гест Украина https://zverok.github.io
Дата: 20.09.12 19:24
Оценка: 9 (1) +1 :)
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Гест, Вы писали:


Г>>Ох уж мне эти теоретики.

Г>>Покажите школьнику
_>...
Г>>И посмотрите на его реакцию.
Г>>Я — показывал.

_>Безотносительно к теме обсуждения, но данный пример это типичная подтасовка и демагогия. Естественно что будет такая разница в восприятие, при использование принципиально разных языков, с разной типизацией! А слабо один использовать?


_>Например возьмём Питон (кстати, а почему его до сих пор нет в списке подсветки форума, хотя он явно популярнее всяких там nemerle?).


Python — на мой личный вкус — вообще чудо "понятности".

Ну вот, пожалуйста:

array = [1,2,3,4,5]

# подход, названный туповатым автором исходной статьи "объектно-ориентированным"
# хотя на деле он, понятно, функциональный
array.each do |e| 
  puts e
end

# императивный подход
# (хотя руби - мой основной язык - это первый раз в жизни я использую его цикл for)
# что о чём-то да говорит
for i in 0...5
  puts array[i]
end


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

Просто у автора исходной статьи такая же инженерчанка, как у AlexRK — люди с таким типом мышления не давали бы прав водителям, которые не могут собрать-разобрать "Жигули" с закрытыми глазами. Поэтому мой первый пример они начнут объяснять с лямбд и функций высшего порядка.
Re[20]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.10.12 07:44
Оценка: 1 (1) -1 :)
Здравствуйте, Ikemefula, Вы писали:

I>Где же тут изменение состояния ?

А его нигде нет. Вам совершенно не нужно "изменение состояния" для того, чтобы объявить фразу императивной.
"Собака лает" — это свойство собаки, а вовсе не изменение состояния. "Пиво по 30 рублей литр — это выгодная сделка" — никакого изменения состояния.

S>>Не, не годится, так как из этого нельзя вывести никакого императива. Один пост назад вас почему-то не смутило отсутствие цели, и вы легким магнием руки аналогичную пословицу подвергли ровно тому же преобразованию.

I>А здесь есть изменение состояния — "менять", так что все в порядке.
Да ничего не в порядке. Вы натягиваете презерватив на глобус и находите общности там, где их нет, и различия там, где их нет.
Зачем?

Даже если вы сумеете построить более-менее непротиворечивую модель мышления, опираясь на теории Лебедева, то это никак не поможет вам приблизиться к вопросу о "трудности" или "нетрудности" императивного vs декларативного программирования.
Потому, что "императивное мышление", о котором говорит Лебедев, никакого отношения к императивному программированию не имеет.
Иперативное программирование отличается от, скажем, функционального вовсе не тем, что оно "указывает, что делать". Оно оперирует изменяемым состоянием некоторого вычислителя. SQL, к примеру, тоже "императивен" в том смысле, что у него все стейтменты представляют собой глаголы в повелительном наклонении. Однако это никак не влияет на его декларативную природу.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Императивное программирование
От: vdimas Россия  
Дата: 10.10.12 17:50
Оценка: -2 :)
Здравствуйте, gandjustas, Вы писали:

V>>Формула для его вычисления ПОШАГОВАЯ. Только это и важно.

G>Это свойство самой формулы или того как ты эту формулу воспринимаешь?

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

V>>Можно посмотреть результаты на каждом шаге.

G>Какие результаты?

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


V>> А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе. Ы-Ы-Ы.

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

Дык, заканчивай читать по диагонали, там всё написано. Я говорил о наглядности в ФП, которая доступна лишь в случае пошаговой трассировки работы программы.

V>>Враки. Я говорю, то, что видел. Рекурсию многие понимали дай бог к концу первого семестра. А императивный цикл дается на 2-3-й лекции и понимается без проблем, даже девочками...

G>При таком подходе к обучению — естественно. Тебе как раз про другой подход говорят.

Нет никакого другого подхода. Даётся ровно один и тот же материал в обоих случаях, вы лишь предлагаете поменять последовательность подачи материала. Так вот, уже на 3-м уроке по программированию изучают циклы и могут писать полезные программы. На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?


G>Если что в большинстве курсов не используется модель подстановки для начала обучения, сразу рассказывают про переменные, память итп, что значительно усложняет понимание банальной рекурсии.


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

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


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

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


G>>>Более того многие вещи в математике рекурсивны по природе. Те же факториалы или числа Фибоначчи.


V>>Они не рекурсивны, а итеративны.

G>Рекурсия — когда одинаковые символы встречаются в обоих частях выражений.

G>F(n) = F(n-1) + F(n-2)

G>Где тут итерация? Опиши последовательность действий для вычисления N-ого числа фибоначчи, докажи что она эквивалентна формуле.
G>Это крайне непростая задача.

Гы, и ты кого-то еще там учишь???
(Кстате, а смысл? Если студент не начился в ВУЗе, и не умеет учиться сам, то это балласт, а не работник.)


V>>К тому же по вышке одновременно читают ряды, так что пошаговость-итеративность вычислений для получения X[i] = F(X[i-1]) — легко воспринимаемое императивное действо.

G>Ну это ты самый простой случай описал. Лучше на примере размена монет напиши.

Лучше устыдись своего примера насчет чисел Фибоначи. Исходная формула описывает получение следующих элементов ряда из предыдущих. Т.е. вместо твоего стыда надо было так:
F[n] = F[n-1] + F[n-2],
где F[i] никакая не ф-ия, а значение элемента ряда.

Ну как, всё ещё "это крайне непростая задача" для императива (С)? ))
Учитель, блин... Мою формулу решит людой ребенок (не-дибиленок) в первый же день изучения какого-нить Бейсика. А для твоей формулы требуются десяток занятий с уже хорошо образованными людьми.
Re[29]: Императивное программирование
От: vdimas Россия  
Дата: 15.10.12 11:07
Оценка: -1 :))
Здравствуйте, artelk, Вы писали:

A>Тема производительности не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.


Так быстро слили? )))

В таком случае, обсуждать сразу нечего. Переупорядочивании вычислений, спекулятивное исполнение веток и прочие весьма нетривиальные преобразования кода могли иметь место только в угоду каким-то бенефитам в плане производительности.
Re[40]: Императивное программирование
От: vdimas Россия  
Дата: 31.10.12 10:10
Оценка: 97 (2)
Здравствуйте, Sinclair, Вы писали:

V>>Для Схемы не может. Целое число там не ограничено.

S>Омг, омг. Это, конечно же, полностью перечёркивает мой аргумент.

Вообще, да. Как и любой другой слишком частный случай.

V>>В любом случае, если компилятор может делать какие-то частичные вычисления (путь даже вычислит первые 12 значений для Схемы), это никак не служит док-вом или даже иллюстрацией к общему случаю, когда компилятор таких вещей делать не может. А мне во всех этих рассуждениях любопытен именно второй вариант, ес-но.

S>Ну так речь как раз о том, где кончаются способности компилятора в общем случае. Императивный компилятор в общем случае вообще не может применять никаких оптимизаций — потому что хрен его знает, зачем программист так написал. Может, там другой поток крутится, который должен иногда наблюдать ровно вот такое изменение состояния, которое кажется бессмысленным. Современные императивные языки предлагают конвенции по управлению этим процессом — скажем, считается, что в локальном коде нет неявных зависимостей, пока я не указал volatile.

Да, ты сам ответил на свой вопрос. Если компилятор полностью видит время жизни некоего значения, то он поступает с ним как хочет. Захочет — вообще выкинет. А если зависимость была отдана "куда-то", и это "куда-то" компилятор отследить не в состоянии... То, любой компилятор ведет себя похожим образом, что ФП, что ИП.


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

S>Да, в исследования этого тумана вкачаны огромные средства — что и позволяет вам наблюдать эффекты оптимизации в императивных языках. Решаются некоторые частные проблемы.
S>Однако, скажем, мне неизвестен компилятор С++, способный превратить OutFirstNFib в O(n) алгорим автоматически:
S>
S>void OutFirstNFib(uint N)
S>{
S>  for(uint i=1; i<=N; i++)
S>    std:cout << Fib(N);
S>}


S>uint Fib(uint n)
S>{
S>   return n < 3? 1 : Fib(n-1) + Fib(n-2);
S>}
S>




А я не знаю ни одного ФП языка, который превратил бы эквивалентный исходный код в O(n).
А если изменишь семантику, то обратное портирование на императив породит совсем другой код.


S>Для того, чтобы компилятор мог эффективно работать в общем случае, нужны явные зависимости.


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

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

Есть еще вариант — это строгие активные объекты. То бишь, чтобы в языке вообще не было возможности создать гонки. В этом плане стоит посмотреть на SmallTalk или Сингулярити с её Exchange Heap. Вот тебе системы, в которых гонки невозможны by design, хотя такие системы всё еще по-уши императивны.

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

Дело за малым — поддержка в компиляторах с текстовых ЯВУ. ))
Или же есть специальные императивные графические языки, которые заведомо избавляют конечный бинарный образ от всех обсуждаемых ужасов императива: http://ru.wikipedia.org/wiki/SFC


S>Речь не о частичных вычислениях, речь о построении эффективной стратегии выполнения декларативного кода. ФП — это когда функция параметризована функцией, обрабатывающей функцию. Всё, что тут может предложить ИП — спекулятивная оптимизация. В лучшем случае — хотспоттинг.


Боюсь, это опять начались точно такие же умозрительные спекуляции, как и обычно. Реально возможности суперкомпиляции ФП-кода очень бедны, т.к. система типов служит ограничителем, который не переплюнуть на этапе подразумеваемой тобой бета-редукции. Жиденько это всё... Т.е. что касается трансформации кода, то гораздо большую свободу трансформаций можно получить уже на регистровом уровне (даже на виртуальных регистрах). Как только убираешь типы, то эффективность суперкомпиляции возрастает многократно, потому что система типов уже не мешает распознавать "похожие" на регистровом уровне вычисления и делать более агрессивные предвычисления, коль эти предвычисленные значения могут пригодиться в большем кол-ве мест.

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

S>Вопросы о том, увидим ли мы прорыв в области ФП до нашей смерти, существенно зависят от банального финансирования.


Смотри в корень. Финансирование это будет не столько в императив, сколько в синхронные автоматы, на которых сейчас сделано 99.999% всей электроники. А императивные языки — это лишь способ гладко лечь на низлежащую вычислительную платформу.

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

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

Просто область асинхронных автоматов очень сложна, и мейнстримовая электроника её старательно шугается... Это что-то вроде Хаскеля в программировании, только еще в 10 раз сложнее. Но потенциально выжимает бОльшую вычислительную мощь с каждого вентиля, т.к. способна работать без "холостых" временных участков, которые есть в тактах синхронных автоматов и которые (уууупс!!!!), очень недетерминированы, на самом-то деле... Бо длительность такта выбирается из предположения, что переходные процессы будут успевать завершаться к началу следующего такта... но это ни разу не гарантировано. Зато этот момент гарантирован в асинхронных автоматах (асинхронный это тот, все состояния которого устойчивы).
Re[4]: TMTOWTDI
От: Курилка Россия http://kirya.narod.ru/
Дата: 24.09.12 08:48
Оценка: 12 (2)
Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Ikemefula, Вы писали:


I>>ни разу не видел начинающего программиста, которому хаскель зашел бы легче, чем Си. Количество кода в сортировке мало чего показывает.


K>А есть опыт сравнения обучения программистов, начинающих с С и с Хаскеля? Вопрос без подвоха, мне действительно интересен опыт, потому как сам я не знаю ни одного примера обучения программированию на хаскеле, как на первом языке.


Вот такая ссылка есть
Re: Императивное программирование
От: Гест Украина https://zverok.github.io
Дата: 20.09.12 17:28
Оценка: 9 (1) -1
Здравствуйте, Ikemefula, Вы писали:

Ох уж мне эти теоретики.

Покажите школьнику

var
  a: array[1..5] of integer = (1,2,3,4,5);
begin
  for i := 1 to 10 do
    writeln(a[i])
end


и

[1,2,3,4,5].each{|e| puts e}


И посмотрите на его реакцию.

Я — показывал.
Re[7]: TMTOWTDI
От: Klapaucius  
Дата: 25.09.12 10:03
Оценка: 9 (1) +1
Здравствуйте, Mystic, Вы писали:

M>Как по мно, суть алгоритма быстрой сортировки в том, чтобы:

M> (1) найти хитрый трюк, чтобы выполнять ее по месту;
M> (2) выбирать элемент из середины, а не голову списка.

M>В противном случае это не быстрая, о очень-очень тормознутая сортировка. Упомянутый исходник на Хаскеле эти основные идеи не иллюстрирует, а значит я не понимаю, на каком основании его можно считать иллюстрацией быстрой сортировки. Это так, хаскель-сортировка


Это, конечно, не быстрая сортирока, но и не "хаскель-сортировка", а сортировка двоичным деревом (просто дефорестированная, развертка и свертка дерева "слиты" вручную). Быстрая сортировка на хаскеле выглядит, например, так:
import Data.Vector.Generic
import qualified Data.Vector.Generic.Mutable as M 

iqsort :: (Vector v a, Ord a) => v a -> v a
iqsort = modify go where
         go xs  | len < 2   = return ()
                | otherwise = do
                    p <- xs `M.read` (len `div` 2)
                    m <- M.unstablePartition (< p) xs
                    go $ M.slice 0     m         xs
                    go $ M.slice (m+1) (len-m-1) xs
                where len = M.length xs
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[5]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.09.12 11:52
Оценка: 3 (1) -1
Здравствуйте, Ikemefula, Вы писали:

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

Дело не в речи, а в способе описания алгоритмов.
На всякий случай напомню, что всё отличие императива — в наличии изменяемого состояния.
Характерным свидетельством декларативности повседневной деятельности является отсутствие циклов. Никто не думает о покупках или планировании отпуска в стиле "так, теперь увеличим номер текущего пункта на единицу, посмотрим, не больше ли он общего количества пунктов списка, и перейдём на шаг один".
Думают в стиле "так, мне надо купить масло, яйца, кефир, сметану и помидоры". В произвольном порядке — как увидел в магазине, так и взял. А то и вовсе "о! у них акция на разливное пиво — возьму-ка я трёшечку".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: TMTOWTDI
От: Klapaucius  
Дата: 24.09.12 08:41
Оценка: 1 (1) +1
Здравствуйте, Ikemefula, Вы писали:

I>Для начинающего естественно использовать именно тот подход, которым он руководствуется в обиходе, например при покупкав магазине или при построении-реализации планов на отпуск и тд и тд и тд.


Ну, в обиходе используется арифметика, которая вообще-то декларативна.

I>ни разу не видел начинающего программиста, которому хаскель зашел бы легче, чем Си. Количество кода в сортировке мало чего показывает.


А есть опыт сравнения обучения программистов, начинающих с С и с Хаскеля? Вопрос без подвоха, мне действительно интересен опыт, потому как сам я не знаю ни одного примера обучения программированию на хаскеле, как на первом языке.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: TMTOWTDI
От: Abyx Россия  
Дата: 02.10.12 11:14
Оценка: 1 (1) +1
Здравствуйте, Sinclair, Вы писали:

S>Характерным свидетельством декларативности повседневной деятельности является отсутствие циклов. Никто не думает о покупках или планировании отпуска в стиле "так, теперь увеличим номер текущего пункта на единицу, посмотрим, не больше ли он общего количества пунктов списка, и перейдём на шаг один".

S>Думают в стиле "так, мне надо купить масло, яйца, кефир, сметану и помидоры". В произвольном порядке — как увидел в магазине, так и взял. А то и вовсе "о! у них акция на разливное пиво — возьму-ка я трёшечку".


список = {масло, яйца, кефир, сметана, помидоры}
for полка in магазин.все_полки()
   for предмет in полка
     if предмет in список or чтото_очень_нужное(пиво)
        мир.переместить(предмет, корзина)
In Zen We Trust
Re[41]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 29.10.12 17:22
Оценка: 1 (1) +1
Здравствуйте, AlexRK, Вы писали:

ARK>Какое, однако, мощное обсуждение идет.

Ну дак тема-то эпическая!
ARK>Например, какие? Пометка функции как чистой, все переменные по умолчанию thread-local, если shared — опять же явно помечать? А лучше вообще без shared.
Ну, я не эксперт в оптимизирующих компиляторах, но в целом мне кажется, что экстремальные ограничения должны себя показать. Т.е. все функции — чистые; все передачи состояния — явные (то есть именно World PrintLn(World oldWorld, string line)); никакого shared.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Императивное программирование
От: Sharov Россия  
Дата: 20.09.12 16:10
Оценка: +2
Здравствуйте, Ikemefula, Вы писали:

и?
Кодом людям нужно помогать!
Re: Императивное программирование
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 20.09.12 17:42
Оценка: +2
I>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.

начинай сразу с объяснения машины тьюринга — там концепций еще меньше..

ps
Если серьезно — то необходимо не минимальное кол-во концепций, а возможность за минимальное кол-во усилий решить реальную задачу стоящую перед пользователем. На основе лишь концепций массив, переменная, if и goto — это сделать очень и очень непросто.
Re[3]: Императивное программирование
От: Гест Украина https://zverok.github.io
Дата: 20.09.12 17:51
Оценка: +1 -1
Здравствуйте, AlexRK, Вы писали:

ARK>Здравствуйте, Гест, Вы писали:


Г>>Покажите школьнику


ARK>Код на паскале читается проще, несмотря на больший объем. Считай, программа последовательно и читается, как есть. Что написано, то и происходит.

ARK>А код на руби школьник — даже если и угадал, что программа делает — я думаю не понял.

Если вам действительно кажется, что "код на паскале читается проще" — поздравляю, у вас инженерчанка!

В коде на руби написано "раз, два, три, четыре, пять — каждый — напечатать"

В коде на паскале написана криптография.

Иными словами, код на паскале ДЕЙСТВИТЕЛЬНО требует объяснения всех вот тех понятий, перечисленных в исходном посте.

Код на руби объясним через "человеческие" понятия, и позволяет сначала сделать что-то интересное, а потом уже по мере необходимости разбирать, как это всё работает и почему.

Г>>Я — показывал.


ARK>Ну, реакция одного школьника, какой бы она ни была, ничего не доказывает и не опровергает.


Кто говорил про одного? Я учителем информатики в школе работал.
Re[4]: Императивное программирование
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.09.12 12:32
Оценка: +2
Здравствуйте, Гест, Вы писали:

Г>Код на руби объясним через "человеческие" понятия, и позволяет сначала сделать что-то интересное, а потом уже по мере необходимости разбирать, как это всё работает и почему.


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

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

Многие практиковали карго-культы в институте. Не понимая смысла отладки, и вообще, как оно выполняется внутри, оно пробовали решать упражнения по аналогии с решением других упражнений. Так из кода поиска максимального значения на паскале они могли составить код поиска минимального значения. Может вставить одно условие. Но если случайными изменениями кода не удавалось заставить его работать, то выполнить задачу было свыше их сил.
Re[6]: Императивное программирование
От: Centaur Россия  
Дата: 24.09.12 15:11
Оценка: :))
Здравствуйте, Roman Odaisky, Вы писали:

RO>«Ответом на этот HTTP-запрос есть этот шаблон, заполненный такими-то данными» — где императивность?


Не надо есть шаблон. Особенно ответом на http-запрос.
Re[13]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 09:23
Оценка: -1 :)
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

>>>Попробуйте расшифровать, как советует нам поступить в той или иной ситуации пословица "не всякий цветок даёт плод".
I>>А что, модальности уже отменили ? Не знал.
I>>"не всякий цветок даёт плод" -> "не стоит ждать плода от каждого цветка"
S>Отлично. Ничего, что это две разные фразы? Или вы считаете их семантически неразличимыми?

Семантически они отличаются модальностью и ничем больше, и это не страшно.

I>>Это заблуждение. Если ты внимательно читал ссылки, то там вобщем легко понять что твоя фраза императивна до безобразия

I>>"собака лает", "машина едет", "корован грабят" — императивны.
S>Отлично. Таким образом, мы выяснили, что неимперативных утверждений не бывает.
S>Или можно привести в студию пример "неимперативной" фразы?

"каждый человек — млекопитающее, Sinclair человек, следовательно Sinclair млекопитающее"
Это что, так сложно ?
Re[19]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.12 20:01
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sinclair, Вы писали:


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


V>Тут этим заняты 100% участников.


S>>Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит.


V>Как это не учат, если даже решение квадратного уравнения даётся в школе как пошаговый алгоритм? К тому же, с ветвлением.


Да ну? Что там сначала надо вычислять b^2 или 4ac ? И где там ветвление? Ветвление предполагает выбор одной из альтернатив, а у квадратного уравнения может быть два корня.

Приведи этот алгоритм на каком-либо императивном языке.


S>>Зато "подставлять выражения в формулу" они у вас же не умеют, несмотря на то, что их этому учат с 5го по 11й класс.


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

Ты не путай вычисления методом подстановки и символьные преобразования. Вторые аццки сложны, первые тривиальны.
При обучении композиции функций как раз требуются сложные символьные выражения.


V>Цимус ситуации, кстате, даже в том, что любое решение, даже будь оно сугубо в формулах, можно разложить на шаги/этапы. Т.е. на некую последовательность рассуждения. То бишь процесс вычисления ф-ий во времени вполне естественнен для понимания. Это даже можно показывать наглядно через отладочную печать или в каких-нить современных пакетах моделирования.

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


I>>>А почему вдруг они стали непрофильными ?

S>>Потому что они изучали математику, а программирование для них — неинтересный спецкурс.
I>>>Я думаю дело в подходе к обучению.
S>>А я думаю, что проще учить программированию постепенно, а не начиная с самых противоестественных для обычного человека концепций.
V>Эта твоя "противоестественность" надуманна как оправдание модному увлечению. А на деле оно приходит лишь с пониманием большого кол-ва вещей. Мыслить по-настоящему абстрактно человек умеет уже в достаточно зрелом возрасте. А чем меньше ребенку лет, тем больше рулит наглядность. Императив же нагляден по своей природе.
И что? Сравни формулу для вычисления корней и любую императивную запись его, посмотрим что нагляднее.


I>>>Преподаватели. Императив требует тоже самое что и функциональщина и программирование вообще — освоение вычислителя.

S>>ФП не требует никакого освоения вычислителя. По крайней мере, на начальных этапах.

V>ФП потребует понимания рекурсии уже на 3-м уроке по программированию, в отличие от простого цикла на 20 GOTO 10... Уууупс!!! Вот и приплызд, бо рекурсию многие студенты понимают дай бог спустя несколько месяцев начала обучения программированию. Что тут требовать от школьников?

Рекурсия элементарна если использовать банальную подстановку. В 100500 раз легче goto. Более того многие вещи в математике рекурсивны по природе. Те же факториалы или числа Фибоначчи.
Re[23]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 10.10.12 19:08
Оценка: +1 :)
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


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

Пошаговая как и WHERE в SQL

V>На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?

В курсе SICP рекурсию дают на лекции 1.

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

Ближе к началу второй половинки 1-ой лекции

V>Лучше устыдись своего примера насчет чисел Фибоначи. Исходная формула описывает получение следующих элементов ряда из предыдущих. Т.е. вместо твоего стыда надо было так:

V>F[n] = F[n-1] + F[n-2],
V>где F[i] никакая не ф-ия, а значение элемента ряда.
То что F не функция, тебе придется показать формально.
Re[82]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 09:58
Оценка: -1 :)
Здравствуйте, gandjustas, Вы писали:

G>>>Ну не сливайся ты так. Ведь никто тебе не говорит что надо забыть C++ и писать на чем-то еще. Тебе ведь говорят что не надо на нем учить программировать, это вредно.

I>>А я по твоему предлагаю С++ использовать для обучения ? Дай цитату.

G>Я не знаю что ты предлагаешь, но тему ты переводишь постоянно. Оставайся в контексте, а то ты на основании рассуждений о C++ делаешь выводы об обучении.


Ты внятно ответь на вопрос — где я предлагаю использовать С++ для обучения ? Есть простой факт — С++ крайне востребован в определенных областях, котрые крайне актуальны.

I>>Обычно императивный код даёт наилучший результат.

G>Ты представляешь объем и сложность императивного кода, который даст сравнимый с SQL результат?

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

I>>SQL это массовый язык, только покрывает мизерную часть задач обработки данных.

G>У тебя есть статистика? Мне кажется что по объему кода для обработки данных SQL обошел на несколько кругов всех остальных. Узкоспециализированные решения на конкретных задачах работают быстрее SQL на этих же задачах, но на то эти средства и узкоспециализированные.

Объема кода много, а вот сценариев очень мало — в основном выборки и примитивный процессинг.

I>>Ресурсы, ввод-вывод — самый простой пример это драйвера, ОС и тд.

G>Драйверам скорость не сильно нужна, ограничение по языкам там от низкоуровневости. Что ты имеешь ввиду под ОС — непонятно, ОС — неоднородная вещь. Вот есть оконный манагер для *nix на haskell.

В чем то ты прав, когда винда зависает от того, что лоток привода закрывается, то часто это означает, что драйвер писал программист который считал что драйверу скорость не нужна.
Вот оконному манагеру скорость точно не нужна, ибо он не занимается низкоуровневыми вещами, а они, в свою очередь, написаны на мега-оптимизированом инструменте.
Re[28]: Императивное программирование
От: artelk  
Дата: 15.10.12 08:18
Оценка: +2
Здравствуйте, vdimas, Вы писали:

V>Разумеется, это как раз не страшно — чем раньше упремся в невычислимость, тем лучше. Страшно обратное, когда комбинаторное сочетание ложных веток далеко вглубь работы програмы потянет на себя на многие порядки больше ресурсов, чем целевая программа. Учитывая, что в мин-макс системе критериев, по которым "доводят" любой компилятор, одним из критериев является эффективность конечного образа, это всё моментально превращается в рассуждения в никуда.

Эффективность конечного образа не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.

V>Подумав 5 мин можно обратить такую "ошибку" на пользу, считай в "точку синхронизации" в вашей воображаемой системе распараллеливаемых/спекулятивных вычислений. Это и так всё понятно...

V>Но, прикол ситуации в том, что на сегодня императив рулит гораздо больше в плане спекулятивных вычислений, чем ФП, т.к. обычное переупорядочивание независимых вычислений в императиве, выполняемое современными компиляторами С++, например, всегда вычисляет такие вещи, которые должны были быть вычислены в любом случае. Теперь сравни с холостой тратой ресурсов на вычислении ложных веток непонятной глубины.
Тема производительности не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.
Re[29]: Императивное программирование
От: artelk  
Дата: 15.10.12 08:51
Оценка: +2
Здравствуйте, vdimas, Вы писали:

A>>Это код на неком ленивом функциональном языке.


V>В таком случае это второй вариант — декларация ф-ий.

Прекрасно, а чем if не функция?

A>>Ф-я main выглядит как-то так:

A>>
A>>main :: IO ()
A>>main = print y
A>>

A>>, что приводит к вычислению значения y.

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

V>В общем, курить бета-редукцию.
Тут, видимо, требуется какая-то особая техника курения.
V>Явные зависимости ф-ий ничего не значат в ФП в плане пошаговости, то бишь твой коммент в коде "// для вычисления y необходимо иметь уже вычисленный x" попахивает непониманием. Нет никакой такой необходимости после подстановки символов.
Ну тогда и "необходимо иметь уже вычисленный аргумент-предикат" так же попахивает непониманием. Нет никакой такой необходимости после подстановки символов.

V>В общем, повторюсь, пошаговость можно получить только явно эмулируя ФП на императивном вычислителе

В частности, эмулируя if.
V> Причем, чтобы сохранить соответствие исходника и происходящему в процессе трассировки, пошагово трассировать нужно непреобразованный ФП-исходник.
Трассировка принадлежит к неязыковым средствам, обеспечивающим доступ к императивному вычислителю, эмулирующему ФП. Ее наличие не влияет на семантику языковых элементов, в частности оператора ветвления.
V>Ну или в некоторых мультипарадигменных ФП-языках, которые не являются полностью чистыми (типа Хаскеля), можно получать пошаговость, т.е. явно заданный порядок вычислений, на специальных императивных механизмах, типа монады IO.
Функционального программирования не существует?
Re[29]: Императивное программирование
От: artelk  
Дата: 15.10.12 15:18
Оценка: +2
Здравствуйте, vdimas, Вы писали:

A>>Естественно, хаки не рассматриваем.

V>Увы, хаки тебе будут нужны для реального эксперимента. В чем заключается хак — уже написал.
Ты уж сначала определись, хаков не может быть в чистом ФП или условного оператора?

A>>А что мешает первому случаю быть синтаксическим сахаром для второго? Невычисление одной из веток будет всего лишь оптимизацией.

V>Да в принципе, если первое выражение нахождения знака числа будет унутре сделано через ветвление, то ничего не мешает. Будет то же самое безо-всяких оптимизаций. Просто бывают такие инструкции, которые некоторых процов, которые умеют помещать в АЛУ знак числа без ветвления.
Ну.. ты понял, вобщем.

V>А в общем случае наверно мешает тот момент, что компиляторы пока плохо различают одну и ту же семантику, выраженную разными способами. Ес-но, как только компиляторы научаться полностью понимать "семантику" происходящего, то это станет не принципиально. Дык, это станет непринципиально для императива и ФП в равной мере, то бишь, опять у ФП никаких преимуществ.

V>Кароч, я тут уже говорил как-то, что со временем ФП будет не особо нужно, бо компиляторы будут сами находить скрытые ошибки императиве, как это сегодня делает тулзина Valgrind, например. Смотри в суть вещей — ФП языки нужны сугубо как костыль для тупых компиляторов образца до начала ~2000-х годов. После этого наступили такие времена, что ведущие компиляторы с того же С++ стали частично суперкомпиляторами и "понимают" намного больше семантики (совершая в итоге намного больше преобразований) чем все компиляторы со всех ФП-языков вместе взятые.
Какой кошмар. Готовишься к конкурсу на звание "Самый альтернативно мыслящий"?! Мой голос за тебя!

A>>Производительность ветвлений на современной аппаратуре не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.

V>Да ради бога. Я лишь одобрил попытку убежать от if.
Попытки убежать от if с целью улучшения производительности, в данном конкретном случае, не было. Пример приводился с другой целью.

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

Ну.. ты понял, вобщем.
Re[45]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.10.12 00:09
Оценка: +2
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Увы мне тебя нечем порадовать. Ты даже haskell считаешь СП, чего уж говорить о первых ФП-языках.


V>Блин, до брехни скатываться не стоило. Покажи, где я считаю Хаскель СП? Я лишь высказываюсь относительно нечистых конструкций, вшитых в этот язык (в современный его вариант и в его расширения).

У тебя проблемы с пониманием чистоты конструкций. Иди медитируй.

V>А первые ФП-языки действительно являются классическими СП-языками, со всеми знакомыми тебе императивными циклами, ветвлениями, переменными и прочим. От ФП там только ФВП. Поэтому, тезис о том, что ФП произошло от СП ес-но в силе. Твоему Хаскелю в его нынешнем виде дай бог десяток лет или меньше, так что заканчивай во всех этих спорах, кто от кого произошел, приводить его в пример.

Давай возьмем один из последних ФП-языков F#. И внезапно он оказывается тоже классическим СП, да?

S>>Да нет, не привел. Либо ты не понял, что я от тебя хочу, либо кривляешься.


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

Ты показываешь ляпы в своих рассуждениях.

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

Вот ты же не понимаешь, а споришь.
S>>Это у тебя серьезные проблемы. Я с тебя просил вот это
S>>http://en.wikipedia.org/wiki/Pure_function#Pure_expressions

V>Я знаю, что ты у меня спросил. Жаль что ты не знаешь. Читай там же:

V>

V>Pure expressions are often referred to as being referentially transparent.

V>Я тебе это показал.
Похоже ты и это не понимаешь

S>>Извини что стейтментами назвал, но if/loop/sequence не работают с выражениями.


V>Похрен. Я тебе скопировал из твоей собственной ссылки фразу, которая ключевая дял понимания происходящего.

Ты этим меня хочешь убедить что присваивание легально в pure-expression?

S>>В детский сад со своими примерами. Это не то, что я просил.


V>Именно то. Просто налицо непонимание св-в чистоты вычислений.

Демонстрируешь его ты

V>>>Возьми для примера Немерле. Там имутабельные переменные, но на них выражается вычислительный процесс явным образом. То бишь, тот же самый императив.

S>>Ты не понимаешь, что такое императив. Походу не справился с определением.

V>Я же сказал — курить теорию автоматов. Без неё понимание императива нереально.

Мне твое "я же сказал" не упирается.

S>>см pure expression


V>Сам смотри внимательней. И заканчивай ты уже этот пинг-понг пустыми постами. Возьми за труд хоть немного помедитировать над ответными аргументами. Все входы и выходы уже даны. См. мой предыдущий пост.

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

S>>Никуда я не забегаю, ты мне эти примеры пишешь уже второй месяц.


V>Дык, тем хуже для тебя.

V>Вопросы на засыпку:
V>- что я имел ввиду под "контекстом вычислений" в этом абзаце?
Да фиг тебя уже знает
V>- при чем тут детерминированность и куда она может пропасть в императиве?
И причем тут детерминированность? Опять расписываешься в непонимании...
Если что, то о потоках ты не со мной разговаривал.

V>- приведи пример пропадания детерминированности?

ReadLine
V>- если справишься с пред. пунктом, попробуй натянуть изобретенный пример(ы) на любой из моих. Получилось?
Получилось, только я же просил pure-expression-ы.

V>Если пройдешь этот квест, поймешь о чем речь.

Извини, я все больше понимаю что ты не в теме.

S>>Как бы там ни было, это не аргумент


V>Это я показывал, что спекулятивное переупорядочивание выполняется только для тех вычислений, которые и так будут выполнены. В отличие от обсуждаемого переупорядочивания на if.

И это не становится аргументом

S>>Меня поражает, ты вроде как соглашаешься с моей поправкой, но делаешь это тоном училки-зануды.


V>Да какая нафик твоя поправка. Читай оригинал еще раз внимательнее:

V>

V>Это я еще молчу о ветвлении на паттерн-матчинге, где в реальности сейчас происходит реинтерпретация памяти в общем случае, согласно значению дискриминанта алг-типа.


V>Твою поправку (якобы поправку) я выделил. Всё было сказано сразу.

А я тебе сразу сказал что ничего ПМ нового не добавляет кроме дополнительных веток.

S>>Медитируй — не медитируй, страшнее жопы (достижимой в if) там ничего не будет.


V>А зря, помедитировать стоило бы. Если в if жопа может быть как результат каких-то затратных вычислений (иначе зачем бы параллелить), то в случае распаковки значений на ПМ получаем жопу как аргумент вычислений еще до их начала. А факт игнорирования аргумента (куда может придти жопа) должен обнаруживаться еще на этапе бета-редукции (у нас же детерминированные вычисления). В общем, если после бета-редукции таки осталась зависимость от жопы, то смысла продолжать вычисления в 99% нет. Остальные 1% я даю как погрешность, связанную с недостаточной реализацией бета-редукции. Хотя, в идеальном абстрактном мире, о котором шла речь в этих фантазиях, и бета-редукция должна быть идеальной. )))

Придется влезть на чужой фронт.
Тебе показывают, что условие может быть вычислено параллельно. Может — это значит только что может и не обязательно значит что что-то будет эффективнее и что надо все бросить и делать только так. Может — это значит всего лишь то что класс вычислимых функци сохранится и что теоретически время останется конечным но не факт что впишется во время существования вселенной. Твои попытки воззвать к оптимальности не отвергают возможности распараллеливания. Всё. Кури, медитируй, ставь себе 2.
Re[40]: Императивное программирование
От: AlexRK  
Дата: 28.10.12 18:58
Оценка: +1 :)
Здравствуйте, Sinclair, Вы писали:

Какое, однако, мощное обсуждение идет.

S>Для того, чтобы компилятор мог эффективно работать в общем случае, нужны явные зависимости.


Например, какие? Пометка функции как чистой, все переменные по умолчанию thread-local, если shared — опять же явно помечать? А лучше вообще без shared.
Re[13]: Императивное программирование
От: Курилка Россия http://kirya.narod.ru/
Дата: 03.10.12 12:06
Оценка: 99 (1)
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Sinclair, Вы писали:


S>>Определённая степень детализации — это ровно "наблюдаемое поведение".

S>>Блондинка понятия не имеет, как устроен гидроусилитель, и что он вообще есть. Ей достаточно знать, что когда поворачиваешь руль вправо — машинка тоже поворачивает вправо. Всё, на этом необходимая детализация заканчивается.

I>Это самое "наблюдаемое поведение" начинают наблюдать примерно с тех пор, когда берут в руки игрушки, велосипеды, самокаты и тд и тд. Продолжается это на уроках физики, дальше появляется опыт как пассажира. В итоге у всех современных людей в голове уже сформирована более-менее адекватная модель с нужной степенью детализации.

I>И при этом я нигде не утверждаю, что надо знать авто на уровне автомеханика.

Вот ещё одно мнение, о том, что ваше "у всех" не совсем наблюдается в реальности.
Re[7]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.12 02:32
Оценка: 16 (1)
Здравствуйте, Ikemefula, Вы писали:

I>Императивное мышление — логическое мышление, предикативное по природе, направленое на то, что нужно сделать, что выполнить, в какую сторону направить действие и тд и тд.

Кто-то из нас смешивает термины "императивное программирование" и "императивное мышление".
Ничего, что они из разных наук? Вас это не смущает?

I>Пример этого императивного мышления "поищи акции на пиво, если есть бери ведро, если нет — бери томантный сок и водку" — это вполне реальнгый пример. В таком вот духе большинство и рассуждает.

Никто так не рассуждает. Жена вообще его отправила за хлебом и сметаной, и никакой водки с пивом она ему не программировала.
Тем не менее, между приведённым рассуждением и императивной программой — пропасть.
Математически это рассуждение вполне себе декларативно. Вы что же думаете, в ФП нет функции выбора? Конечно же есть.

Сознание "среднего" человека гораздо больше похоже на эрланг. Незначительная его часть занята "потоком управления" в императивном стиле, который отвечает за выполнение текущей задачи (например, "надо доехать до работы"). Основные действия управляются данными, поступающими на вход, и имеют крайне короткий контекст. Я же вам не зря привёл пример про акцию с пивом. Вся "программа", которая управляет человеком — это предикат вроде "пиво по 35 рублей — это выгодная сделка". Он сидит себе где-то в сознании, вместе с соображениями типа "вобла — вкусно" и "мужик сказал — мужик сделал". Нет никакого императивного алгоритма типа "проверить все товары на предмет их стоимости". Есть схема стимул — реакция. Увидел пиво — взял пиво. Всё, "программа" отработала.
Попытка описать поведение человека в супермаркете при помощи императивной программы обречена на провал.
Даже если вы откажетесь от общего случая, и попробуете описать крайне целеустремлённого человека, который пришёл за конкретным списком покупок, то вы встрянете в момент выбора заменителей. Внезапно окажется, что наиболее близкая модель к тому, как человек принимает покупательское решение — функциональная. Потому что детальный порядок, в котором он мечется между полками и то кладёт, то вынимает из корзинки йогурты, совершенно неважен — а это и есть "императивная" составляющая его программы. Важно то, какие признаки он считает значимыми, а какие — нет.

I>""о! у них акция на разливное пиво — возьму-ка я трёшечку"" — это тоже императивное, т.к. направлено на то, что нужно сделать.


I>Императивное мышление оно по природе предикативно, то есть, выражет состояние. "возьму-ка я трёшечку" — предикативно. Есть акция на разливное пиво — предикативно Потому весь твой пример вобщем про императивное мышление. Вот "полная трёшечка" — это не будет предикативным, как ни странно.

Простите, но вы пишете чушь. Предикативность мышления — это идентификация объектов на основе их признаков.
Вы же пользуетесь умнообразными словами, совершенно не понимая их смысла.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: Императивное программирование
От: artelk  
Дата: 18.10.12 11:55
Оценка: 8 (1)
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


V>>>А как насчет вычислимости ложной ветки? Так и не понял примера с факториалом?

A>>
A>>uint fact(uint arg) {
A>>  if(x < 2)
A>>    return 1;
A>>  else
A>>    return arg * fact(arg - 1);
A>>}
A>>

A>>Тут выражение в первой ветке можно вычислить до предиката, а можно и после.
V>В первой ветке константа, там нечего вычислять. Вторая гораздо интереснее.
А как же "2. Если предикат вычислен, то успешная ветка тоже обязательно будет вычислена."?
Вот, еще реализация придумалась:
  1. Запускаем 2 потока для веток
  2. Ждем случайное (например, в интервале [0, С1+arg*С2]) количество тактов процессора
  3. Вычисляем предикат
  4. В зависимости от значения предиката, останавливаем поток ненужной ветки (если он еще работает)
  5. Ждем поток нужной ветки (если еще не отработал)
  6. Берем результат из потока нужной ветки и возвращаем

V>>>Ну хорошо... а как насчет корня из отрицательного числа? А как насчет деления на 0? Ведь реакция вычислителя в процессе вычисления должна сильно разниться для правильной и ложной веток в твоей умозрительной системе.

A>>"Значением" ветки будет (_|_).
V>К сожалению, это унылый хак системы типов, нарушающий всякую чистоту ФП. При таком раскладе чистое ФП не существует, ты прав. )))
Нет, это не хак системы типов. Это возможная реализация императивного исполнителя.

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

V>data ResultOrError x = Result x | Error ErrorInfo
Язык и систему типов не трогаем.

A>>Если потом, после вычисления предиката, будет выбрана вторая ветка, значение всего выражения будет определяться ей.

V>ОК, даже если предыдущий механизм ResultOrError компилятор добавит сам, как часть некоего сценария "отложенной" генерации исключительных ситуаций, то бесконечное зацикливание на ложной ветке вычисления факториала не сразу-то и понятно как остановить. Тут только начни рассуждать в эту область и попробуй расширить на общий рекурсивный случай (а других и нет в ФП) и сразу станут видны все подводные камни. В общем, до тех пор, пока не избрели формальной методики для обсуждаемого, скорее прав я, чем вы.
Реализация с потоками решает проблему бесконечного зацикливания, однако не имеет предопределенной упорядоченности условного оператора.
Re[31]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 11:50
Оценка: 1 (1)
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


A>>Прекрасно, а чем if не функция?


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

f x = a*x + b

тоже не_обычная функция. Сначала будет обязательно вычислено умножение и лишь потом сложение
Re[4]: Императивное программирование
От: AlexRK  
Дата: 20.09.12 18:09
Оценка: +1
Здравствуйте, Гест, Вы писали:

Г>Если вам действительно кажется, что "код на паскале читается проще" — поздравляю, у вас инженерчанка!


Да, действительно кажется.

Г>В коде на руби написано "раз, два, три, четыре, пять — каждый — напечатать"


Хм. А что там за "e"? Или такие мелочи на данном уровне абстракции не важны?

Г>В коде на паскале написана криптография.


В коде на паскале написано:
1) объявить структуру данных "массив" с пятью элементами;
2) взять с первого по десятый элементы массива и напечатать.

Если вам действительно кажется, что "в коде на паскале написана криптография" — поздравляю, у вас рубичанка!

Г>Иными словами, код на паскале ДЕЙСТВИТЕЛЬНО требует объяснения всех вот тех понятий, перечисленных в исходном посте.


А код на руби не требует объяснений функций высшего порядка, конечно же. Божией волею знание этого проникает в головы школьников.

Г>Код на руби объясним через "человеческие" понятия, и позволяет сначала сделать что-то интересное, а потом уже по мере необходимости разбирать, как это всё работает и почему.


Код на паскале тоже объясним через человеческие понятия. Причем он содержит меньше сложных концепций, чем руби-код.

Г>Кто говорил про одного? Я учителем информатики в школе работал.


Окей, скольким же вы показывали и каковы результаты?
Re[2]: Императивное программирование
От: alex_public  
Дата: 20.09.12 19:04
Оценка: +1
Здравствуйте, Гест, Вы писали:

Г>Ох уж мне эти теоретики.

Г>Покажите школьнику
...
Г>И посмотрите на его реакцию.
Г>Я — показывал.

Безотносительно к теме обсуждения, но данный пример это типичная подтасовка и демагогия. Естественно что будет такая разница в восприятие, при использование принципиально разных языков, с разной типизацией! А слабо один использовать?

Например возьмём Питон (кстати, а почему его до сих пор нет в списке подсветки форума, хотя он явно популярнее всяких там nemerle?).

Императивный пример:
a=[1, 2, 3, 4, 5]
for i in range(len(a)): a[i]=a[i]*a[i]
print a

Функциональный пример:
a=[1, 2, 3, 4, 5]
a=map(lambda x: x*x, a)
print a

Ну и какой из этих двух примеров проще для восприятия школьником? ) Фиг знает уже...

Да, кстати, лично мне оба не нравятся и я предпочитаю третий питоновский вариант, через генераторы. Который кстати выглядит чем-то промежуточным:
a=[1, 2, 3, 4, 5]
a=[x*x for x in a]
print a
Re: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 20.09.12 20:50
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>http://dev.by/blog/67127#devcut1

I>http://learncodethehardway.org/blog/AUG_19_2012.html

I>

I>А теперь перечислим концепции, с которыми нужно познакомить читателя, чтобы объяснить ему, как работают, соответственно, циклы .each и for. Начнем с .each:
I> 1.Переменные
I> 2.Массивы
I> 3.Перечни (enumerables)
I> 4.Наследование
I> 5.Примеси и их связь с множественным наследованием
I> 6.Передача и диспетчеризация сообщений
I> 7.Вызовы функций
I> 8.Блоки, передаваемые вызовам функций
I> 9.Вставка переменных в блоки
I> 10.Область видимости – в частности, при работе с блоками


Мне повезло, я не знаю Ruby. В приведенном примере с each не увидел:
1) перечней или массивов, там явно что-то одно
2) Наследования, примесей и диспетчеризации. На таком уровне обучения можно .each рассматривать как бинарный оператор для arr и того что внутри скобок.
3) Блоки, передаваемые вызовам функций, Вставка переменных в блоки, Область видимости – в частности, при работе с блоками — WTF? Там есть простая лямбда функция, без всяческих замыканий.

Итого: переменные, вызовы функций, последовательности, лямбда-функции (анонимные функции).


I>

I>А что насчет циклов for?
I> 1.Переменные
I> 2.Массивы
I> 3.Оператор if
I> 4.Команды перехода (goto или jump)

I>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.


А разве для for\in не надо понимать те же самые последовательности? Автор что-то лукавит.


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

Поэтому научив последовательностям (как они работают, а не как устроены) и each\map\fold\filter\flatmap\какие_там_еще_функции можно ожидать что человек таки напишет программу, такую что другой человек её поймет.
А вот если обучать массивам, goto, присваиваниям итп, полученная программа будет понята только компьютером, и то не факт что правильно.
Re[9]: Императивное программирование
От: Roman Odaisky Украина  
Дата: 24.09.12 12:57
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Декларативная арифметика осваивается через императивный период — на пальцах, на палочках, счетах и тд и тд. Только после этого люди могут писать 2+2 и понимать, что же это означает.


Счеты — не компьютер, а только средство хранения данных. Оно не проделывает действия. А 2+2 — это как раз квинтэссенция декларативности, это выражение не подразумевает никакого действия само по себе (да, я помню термин «арифметическое действие»). Может, у Васи было два яблока и ему дали (действие) еще два, а может, у него было два в одном кармане и два в другом. 2+2=4 — это не «x = 2; x += 2; assert(x == 4)», это не переход объекта из состояния «2» в состояние «4» под воздействием чего-то, что увеличивает его на 2, а просто математический факт. Пусть требуются определенные действия для того, чтобы выяснить, чему же равняется x, если x = 31415926 + 27182818, но главное же не сами действия, а результат.
До последнего не верил в пирамиду Лебедева.
Re[8]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 13:15
Оценка: +1
Здравствуйте, Roman Odaisky, Вы писали:

I>>В задаче для получения результата нужно организовать вычисления.


RO>Именно. Компьютер-то императивный внутри.


Это текущий уровень развития технологий.

RO>Но если используемый язык достаточно умен для того, чтобы мы ему сказали, чтó нам надо, а он чтобы сам организовал, как этого добиться, почему так и не сделать?


Как правило такие языки непригодны для широкого использвания. Побаловаться со списками, повычислять факториалы получается, а как обработать звук — надо садиться за С++.

RO>Мы же пишем всё время z = x + y, а процессор на самом деле делает z = x; z += y. Это же не повод так и писать самим.


Да пиши как удобно. В статье речь про обучение. В общем случае отказаться от императивной стадии просто не получится.
Просто потому, что результаты на ранних стадиях никак не коррелируют с результатами в более поздний период.
Re[5]: TMTOWTDI
От: Roman Odaisky Украина  
Дата: 24.09.12 21:26
Оценка: +1
Здравствуйте, Mystic, Вы писали:

RO>>Хаскель: «Отсортированый список — это отсортированный список элементов хвоста, меньших головы, затем голова, затем отсортированный список элементов хвоста, не меньших головы».


M>С таким пониманием я бы не рискнул программировать.


Встречаются и более рисковые люди.

M>Потому как в случае списка из 10 000 элементов, почти отсортированных (одна транспозиция), мы получим производительность 50M сравнений, и столько же элементов в динамической памяти. Чтобы хоть как-то вразумительно работать, нужно в таком коде постоянно видеть C++-аналог.


Именно. И не наоборот. Только поняв суть алгоритма, можно спускаться с небес на землю и думать, как же его реализовать. По коду на Хаскеле сразу ясна суть и потом уже можно начать выяснять, где узкие места и как это оптимально реализовать. Я вспоминаю, как впервые увидел код quicksort в какой-то книжке по Паскалю — там не было понятно вообще ничего, зато, наверное, работал он быстро.

Мы здесь вроде ведем речь об обучении? Какой подход лучше: отправлять сразу делать всё в императивном стиле, или дать возможность записать алгоритм в человекочитаемом виде, сначала заставляя программу работать пусть медленно, но правильно (ура!), а потом предлагая ученику поразмыслить, как ее ускорить?
До последнего не верил в пирамиду Лебедева.
Re[9]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 21:08
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:



G>>Ты можешь привести пример рассуждений, которые может провести здоровый человек (не программист), которые могут дать такой результат?


I>Я привел все нужные примеры. Покупки в магазине, планирование, реализация планов и тд и тд.

И где тут циклы? Тут последовательности. Список покупок, план действий — это все последовательности элементов. Конечно цикл foreach — тоже способ обработки последовательности, но кроме него много других способов.
Re[13]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 10:31
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Ikemefula, Вы писали:


I>>Здравствуйте, gandjustas, Вы писали:


I>>>>Мозгу для принятия решения в любой ситуации нужна более менее адекватная модель. Проблема заключаетсяв том, что эту модель нельзя загрузить извне.


G>>>Причем тут мозг? Мы говорим про программы? Модель принятия решения мозгом бесконечно далека от вычислительных моделей.


I>>Мы говорим про обучение программированию с целью решения современных задач, а не вообще, попрограммировать ради программирования.

G>Решение современных задач складывается из поиска правильных инструментов и комбинирования их в решение. Причем тут вычислительная модель и устройство инструментов?

I>>>>Твой вопрос был про незнание особенностей конкретной реализации.

G>>>Это ты так понял вопрос.

I>>value-type это конкретная реализация, в абстрактной вычислительной модели ничего такого нет и быть не может.


G>Что-то я перестаю понимать что ты имеешь ввиду под "абстрактной вычислительной моделью" Может расскажешь?


машина тьюринга — абстрактная модель. В ней нет никаких value-type и тд и тд.

G>Вот вычислительная модель CLR абстрактна, в том смысле что конкретной реализации нет. Лямбда-исчисление тоже абстрактно. При некоторых ограничениях эти модели дают одинаковый результат. При этом модели сильно разные. Чему ты предлагаешь обучать?


Начинать с обычного императивного программирования и формировать нужные абстракции. Дальше можно и лямбда счисление и CLR и все что угодно.

G>Ок, бери бета-редукцию. Примитивнее не придумаешь. Любому знающему арифметику можно объяснить за 2 минуты.


Идёт. Мой сын которому скоро 5, как раз осваивает арифметику. Устроим сеанс мастер-класса, ты будешь объяснять ему бета редукцию. Не дай бог он этого не поймёт — пеняй на себя.
Re[9]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.09.12 10:31
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>В программировании ровно то же — у человека нет никаких абстракций в голове, которые позволят работать с map. Map, то есть проекция, это очень высокоуровневая абстракция. Их невозможно привить человеку каким то хитрым способом.

Эту абстракцию изучают в школе под видом y=f(x)
Re[15]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.09.12 12:42
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Запиши лучше что для понимания map организация вычислений не нужна


I>Нужна. Это хорошо объясняет, почему люди с матбекграудом пишут код который императивнее некуда.


Это хорошо показывает как ты строишь логические цепочки. Одним бездоказательным утвреждением объясняешь очевидные истины.
Да, есть люди с матбэкграундом, которые пишут императивный код. Есть и другие. А есть и те, которые пишут и императивный и декларативный код. Среди них есть люди с матбэкграундом и без.
Вопрос существования таких людей не оспаривается. А для того что бы говорить о тенденциях нужны выборки.
Re[3]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.09.12 09:09
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Для начинающего естественно использовать именно тот подход, которым он руководствуется в обиходе, например при покупкав магазине или при построении-реализации планов на отпуск и тд и тд и тд.

Никто не использует императивное программирование при построении/реализации планов на отпуск.
А ваши комментарии всего лишь означают, что вы неверно понимаете отличия императивного программирования от декларативного.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 11:40
Оценка: -1
Здравствуйте, samius, Вы писали:

I>>Отсюда ясно, что f(x) это 1, map, т.е.проекция, это 2.

S>Ничего не понял, что и откуда ясно. f(x) — это проекция, map — тоже проекция. Чем тебе f(x) не абстракция для map?

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

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

S>И причем тут "не обладая вообще никакими знаниями-умениями"? И чем в этом аспекте for лучше?


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

I>>Я видел достаточно много кода который писался именно математиками на разных проектах на разных языках из разных стран в разных областях.

S>Много ты видел кода, написанном математиками на хаскеле, например? Или ты судишь по коду на императивных языках?

На императивных. Что интересно, программисты ту же математику на тех же языках пишут куда более качетвенно и гораздо более декларативно.
Так что похоже, что дело не в языке а в прокачке определенных скилов. Одной математики для программирования недостаточно.
Re[19]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.09.12 12:33
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Отсюда ясно, что f(x) это 1, map, т.е.проекция, это 2.

S>>Ничего не понял, что и откуда ясно. f(x) — это проекция, map — тоже проекция. Чем тебе f(x) не абстракция для map?

I>И то и другое проекция, но в одном случае это просто закон, а в другом это не только законо, но и вход, выход и тд и тд. То есть сюда уже вложено понятие списков, типов, особенностей реализации + специфика конкретной вычислительной модели, то есть, всего что необходимо и достаточно для организации вычислений.

Т.е. для того что бы решить задачу без map for-ом, нам не нужны теперь ни типы, ни списки/массивы? А что такое организация вычислений?

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

Одного for-а тоже не достаточно для обучения программированию.

S>>И причем тут "не обладая вообще никакими знаниями-умениями"? И чем в этом аспекте for лучше?


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

С какими такими инструкциями сталкивается покупатель холодильника или кофемашины что он сразу лучше понимает for?

S>>Много ты видел кода, написанном математиками на хаскеле, например? Или ты судишь по коду на императивных языках?


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

I>Так что похоже, что дело не в языке а в прокачке определенных скилов. Одной математики для программирования недостаточно.

А откуда вообще взялась мысль что математик на императивном языке будет писать качественнее и декларативнее программиста? Т.е. если допустим взять среднего сфероконического математика, который не занимается программированием (хотя бы так часто, как это делает профессиональный программист), и взять среднего сфероконического программиста, который занимается программированием каждый день кроме выходных и отпуска, то за счет чего математик должен программировать лучше? Кто утверждал что одной математики для программирования достаточно? Особенно на императивных языках?!??!
Вобщем мне непонятно откуда у математика возьмутся способности к программированию на императивном языке лучше чем у программиста.
Re[21]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.09.12 14:04
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Т.е. для того что бы решить задачу без map for-ом, нам не нужны теперь ни типы, ни списки/массивы?


I>Нужны. for это "что сделать". map описывает результат.

Раз нужны, значит for в этом отношении не лучше.

>>А что такое организация вычислений?


I>Да все то же — процессор не знает ни математики, ни алгоритмов. Твоя задача сделать так что бы получить нужный результат несмотря на эти недостатки.

Как пользователю высокоуровневого языка мне нет дела до процессора и организации вычислений. Есть язык, у него есть семантика. Этого достаточно в большинстве случаев. Во всяком случае, с for-ом то же самое. Детям рассказывается его семантика, а не организация его выполнения процессором.

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

S>>Одного for-а тоже не достаточно для обучения программированию.

I>Это очевидно. Но факт в том, что императивное мышление прокачано у всех, декларативное — только у некоторых, А программировть учить нужно и тех и других.

Я не вижу связи между императивным мышлением и императивным кодом.

S>>С какими такими инструкциями сталкивается покупатель холодильника или кофемашины что он сразу лучше понимает for?


I>С любыми вообще говоря. Инструкции это еще один из примеров, не лучше и не хуже чем те что я приводил. Я дал ссылку где то здесь же рядом, для Синклера, можешь посмотреть там про императивное мышление.

Да, я слежу. Но связь между императивным мышлением и кодом не очевидна по этой ссылке.

I>Дальше я извини скипнул ен читая, есть причины.

переживу
Re[23]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 27.09.12 14:43
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Раз нужны, значит for в этом отношении не лучше.


I>Лучше потому что хорошо соотносится с императивным мылением.

Чем же map хуже for-а соотносится?

S>>Как пользователю высокоуровневого языка мне нет дела до процессора и организации вычислений. Есть язык, у него есть семантика. Этого достаточно в большинстве случаев. Во всяком случае, с for-ом то же самое. Детям рассказывается его семантика, а не организация его выполнения процессором.


I>Это справедливо только для того случая когда ты освоил этот высокоуровневый язык.

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

S>>Я не вижу связи между императивным мышлением и императивным кодом.


I>Императивный код это последовательность действий — что [с]делать. Императивное мышление вобщем тоже "что делать", только модальности разные.

Императи́вное программи́рование — это парадигма программирования, которая, в отличие от декларативного программирования, описывает процесс вычисления в виде инструкций, изменяющих состояние программы.

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

I>>>С любыми вообще говоря. Инструкции это еще один из примеров, не лучше и не хуже чем те что я приводил. Я дал ссылку где то здесь же рядом, для Синклера, можешь посмотреть там про императивное мышление.

S>>Да, я слежу. Но связь между императивным мышлением и кодом не очевидна по этой ссылке.

I>Разумеется, ссылка то про интуицию Программирование требует логического мышления. Одно уже прокачано, а второе надо прокачивать. Вопрос — каком способом будет пользоваться новичок ?

Что прокачано? Манипулирование изменением состояния программы? Боюсь, что это новый скилл для начинающего программиста.
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 16:23
Оценка: -1
Здравствуйте, igna, Вы писали:

I>Ты передергиваешь, на самом деле это просто список покупок:


[купить]

I>- молоко

I>- сыр (Рокфор или Моцарелла)
I>- колбаски Охотничьи, два десятка
I>- яйца, два десятка
I>- Очаково Черное, две бутылки

Так понятно ?
Re[6]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.12 02:45
Оценка: +1
Здравствуйте, igna, Вы писали:

I>Ты передергиваешь, на самом деле это просто список покупок:

I>- молоко
I>- сыр (Рокфор или Моцарелла)
I>- колбаски Охотничьи, два десятка
I>- яйца, два десятка
I>- Очаково Черное, две бутылки
Там (в жизни) всё ещё интереснее. Потому, что сыр часто не "рокфор или моцарелла", а "сыров разных три-четыре вида для 'сырной тарелки'".
"Колбаски охотничьи" легко превращаются в "оленину вяленую", потому что "колбасок не было". Попробуйте-ка записать выбор трёх-четырёх видов сыров в виде императивного алгоритма.
А в декларативном виде мы всего лишь запишем несколько требований к набору сыров, причём эти требования будут иметь различные приоритеты.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.09.12 11:43
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>>>Раз нужны, значит for в этом отношении не лучше.


I>>>Лучше потому что хорошо соотносится с императивным мылением.

S>>Чем же map хуже for-а соотносится?

I>Уровень абстракции НАМНОГО выше. Абстракции нужно прокачивать, а не спускать сверху. Буде возможность спускать абстракции сверху, весь минимум средней школы, университета и послеуниверситетского образования сводился бы к умению читать и писать.

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

I>>>Это справедливо только для того случая когда ты освоил этот высокоуровневый язык.

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

I>Правильно. Освоил, это значит, что определенные действия, рассуждения автоматизировались считай до рефлексов.

I>Пропустить этап освоения ? Извини, до токого просветления я еще не подымался.
Что? Семантику без процессора освоить не можешь? Извиняю. Пожалеть?

S>>

S>>Императи́вное программи́рование — это парадигма программирования, которая, в отличие от декларативного программирования, описывает процесс вычисления в виде инструкций, изменяющих состояние программы.


I>Сначала — что делать, что сделать. А вот будет ли это изменением состояния программы — дело десятое.

Тебе десятое, а определение это требует.

S>>Соответственно императивный код — это код, описывающий инструкции, изменяющие состояние программы.


I>out port, value


I>Где тут изменение состояния программы ? Просто пример корявости википедии.

Да, википедия не совершенна. Инструкции по порче мира туда же. Что бы ты состояние в файл не прятал.

S>>Посмотри на функциональный факториал или квиксорт, там тоже увидишь последовательность действий "что сделать". Ну типа, взять элементы списка меньше первого, вызвать для них рекурсивно qsort...


I>Это ты сам так хочешь представить программу. Что сделать в ФЯ появляется только в момент ввода-вывода и нигде больше. До этого ты просто описываешь законы.

Так последовательность действий определена законом? Что фильтровать надо перед тем как рекурсивный qsort вызывать, а не после? Можно вообще все тело определение qsort считать отдельной инструкцией-законом по выполнению сортировки.
Так что "что делать (сортировать)" написано и в императивном и в функциональном коде. А отличаются они наличием изменяемого состояния.
Если бы миры отличались лишь оттенком наклонения, то в императивном языке нельзя было бы писать функциональный код. Если будешь возражать, скажи, в какой момент инструкция превратилась в закон при переходе от кода
var a = 5;
a += 10;

к коду
var a = 5 + 10;

А еще у законов нет вычислительной сложности.

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


I>Не аналогии, а причины.

Какие причины?

I>>>Разумеется, ссылка то про интуицию Программирование требует логического мышления. Одно уже прокачано, а второе надо прокачивать. Вопрос — каком способом будет пользоваться новичок ?

S>>Что прокачано? Манипулирование изменением состояния программы? Боюсь, что это новый скилл для начинающего программиста.

I>Прокачано свойство умышленно передёргивать.

Дык, накачаешься тут.
Новичек будет пользоваться тем способом, который не потребует прокачки чего-то лишнего и непонятного. В map ему все доступно с 5-го класса (примерно). Может саму реализацию map-а он не напишет, но по делу применить сможет наверняка раньше чем for.
Re[14]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 10:00
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Семантически они отличаются модальностью и ничем больше, и это не страшно.

Да? А мне казалось, что одна из них — констатация факта, в которой вообще нет никакого субъекта.
А вторая побуждает субъекта к некоторым действиям (точнее, бездействиям).
Между ними ровно такая же разница, как и между императивным и функциональным программированием.

I>>>Это заблуждение. Если ты внимательно читал ссылки, то там вобщем легко понять что твоя фраза императивна до безобразия

I>>>"собака лает", "машина едет", "корован грабят" — императивны.
S>>Отлично. Таким образом, мы выяснили, что неимперативных утверждений не бывает.
S>>Или можно привести в студию пример "неимперативной" фразы?

I>"каждый человек — млекопитающее, Sinclair человек, следовательно Sinclair млекопитающее"

I>Это что, так сложно ?
Ну конечно же да. Ведь вы берёте два предикативных утверждения, которые по-вашему императивны.
Применяете к ним третье, неявное утверждение (которое оставлено за кадром). Получаете четвёртое.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 10:15
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>А ты в курсе, в каком классе начинают "рисовать зверят на координатной плоскости по набору координат" ?

В моё время это было в _пятом_ классе (т.е. в 11 лет).
Именно там вводили понятие "график функции". И к "окончанию школы", которое наступало через шесть лет после этого, выпускники умели в математике уже очень-очень много всего достаточно абстрактного.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[29]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 01.10.12 11:24
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Что ты проверял? Наличие у детей абстракции, позволяющей понять применение функции к последовательности элементов? Ты проверял на тех, кто график функции по точкам не может нарисовать? Где ты их берешь таких особо одаренных?


I>Твои домыслы я не комментирую.

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

I>А ты в курсе, в каком классе начинают "рисовать зверят на координатной плоскости по набору координат" ?

Зверят мы рисовали в 4м. Тогда же строили графики несложных функций по точкам. В 7-м строили графики практически по-взрослому с элементами мат-анализа. Не говоря уж о том что в школьном курсе геометрии есть такие понятия, как проекция точек на прямую/плоскость и линий на плоскость. Хрен знает в каком классе.

I>Вычисления не организовывал и это не мешало считать логарифм.

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

S>>Мне вообще непонятно, почему ты знания по теме программирования черпаешь в психологии, там что, ближе чем в википедии? А чо не в медицининском справочнике?


I>Знания по преподаванию черпаются в педагогике, психологии и много где еще. Странно, да ? Представь себе, здесь программирование ничем не отличается от физики или химии или русской литературы.

Действительно странно. Если бы мне в ВУЗ-е математику и программирование читали психологи и много еще кто, я бы наверное был психологом или еще кем.

I>>>"порча мира" "птица летит" == "портит мир" , так понятно ? Прикинь, каждый момент времени мир не такой, как раньше, потому что птица его портит

S>>Я понял, что ты написал, но не понял, к чему.

I>Любое действие изменяет состояние мира. В императивном программировании мы всегда указываем последовательность действий и это автоматически означает что состояние мира будет изменяться.

Определению это не интересно. Отличие императивного программирования в том, что оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром.

I>>>Я же уже сказал — нужен ввод вывод. Без него программа будет просто описанием какой нибудь хрени.

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

I>Без ввода-вывода функциональная программа это просто текст.

Императивная — тоже.

I>>>Оно есть и там и там

S>>Покажи мне его в функциональном qsort-е.

I>В функциональной программе состояние мира изменится в момент ввода-вывода согласно той декларации которую ты вкладываешь в программу.

Покажи изменение состояния программы.

S>>В C# можно выбирать вычислительную модель? Что-то я не помню такого в опциях...


I>Твои домыслы я не коментирую.

Тогда проккомментируй, как ты выбираешь вычислительную модель

I>>>Правильно. А у map — есть.

S>>Означает ли это что map не закон?

I>map подразумевает расход ресурсов, т.е. память, время, вычислительную сложность и тд.

И какой вывод?

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


I>см мой ответ igna, а твои домыслы я снова не коментирую.

В том ответе всего лишь _твои_ домыслы, которые веской причиной не являются, ибо не связаны логикой.

I>>>Чушь. Как только дело дойдет до ввода-вывода все его познания резко закончатся.

S>>А в чем проблема?

I>Проблема в том, что здесь и начинается деятельность которой он до этого ни разу не занимался — расход ресурсов, время, вычислительная сложность и тд и тд. Отсюда вдруг вырастают структуры данных, алгоритмы и тд и тд которые ему до этого ни разу не были нужны.

Ты так об этом пишешь, будто все это беда лишь функционального map-а, и нисколько не нужно для императивного for-а. К тому же, ты сначала пишешь что проблемы представляет функциональный ввод-вывод и напрочь забываешь об этом в пояснении.

S>>Или ты думаешь что познаний новичка (который еще не знает map и for) резко достаточно для понимания (ручной) организации строк, вычисления cin/cout или списков аргументов в printf?


I>Твои домыслы я обратно не коментирую.

Конечно, ведь твоя теория этого не выдержит.

S>>Когда я работал во ВНИИ, была у меня группа новичков. И продакшн пилили. Хоть и были поводы для недовольства, никакой непроходимости с понятием "проекция" они не испытывали.


I>Ты их учил программировать полностью с нуля, то есть до этого они программирование ни в каком виде не пробовали, не знали, не проходили ?

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

S>>А вот такие ученики, что не знают for, мне не попадались. И посторонних людей с улицы до продакшна не доводил.


I>А мне попадались. Потому что люди вообще не умели программировть до того как пришли ко мне.

Надо полагать что их при этом брали на работу программистами? Или ты ведешь кружок?

S>>Но речь не обо мне. Расскажи лучше, каких конкретно абстракций не хватает твоим ученикам для понимания map?


I>расход ресурсов, время, вычислительная сложность, структуры данных.

Т.е. для for-а им абстракций хватает, а для map- нет?
I>Все что они могут это абстрактный f(x) при этом
I>1. не все, а только процентов 10
I>2. не сразу, а к окончанию школы
Такая статистика, конечно, удручает. Но все равно можно сделать вывод что как минимум программы школы достаточно для того что бы овладеть абстракцией проекции. Не сама же она сваливается на 10% учеников 5 лет спустя после ознакомления с ней в школьной программе?

>>И как они без этих абстракций пилят в продакшн в конце концов?


I>Без них они ничего не пилят в продакшн. Это у тебя новички умеют все подряд да без освоения.

Я не говорил что без них. Я говорил что не наблюдал проблем с пониманием проекции. Да и ты не назвал ни одной абстракции, которая бы отличала map от for-а, кроме f(x).
Re[7]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 07:34
Оценка: -1
Здравствуйте, Abyx, Вы писали:

A>
A>список = {масло, яйца, кефир, сметана, помидоры}
A>for полка in магазин.все_полки()
A>   for предмет in полка
A>     if предмет in список or чтото_очень_нужное(пиво)
A>        мир.переместить(предмет, корзина)
A>

Замечательно. И что, вы полагаете, что реальные индивидуумы в реальной жизни действуют именно по этому алгоритму?
Тогда я вас разочарую — нет, не действуют они по этому алгоритму. Реальный алгоритм там очень fuzzy, и включает массу неэффективностей и повторов.
И это при том условии, что у человека есть заранее подготовленный список покупок. Часто его нет, и покупки производятся исходя из программы типа "чего-нибудь на ужин".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 12:27
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>И при этом я нигде не утверждаю, что надо знать авто на уровне автомеханика.

Ну так вот наблюдаемое поведение алгебраических абстракций начинают наблюдать примерно с пятого класса. И к первому курсу мы вправе ожидать от произвольного студента способности хотя бы подставить x*y вместо a в выражении (a + b)^2 = a^2 + 2ab + b^2.
Все необходимые навыки для освоения программирования уже есть.
Человека, который знает про машину ровно столько, сколько можно узнать при освоении детской тележки с колёсиками, обучают вождению за 30 часов.
Человека, который в качестве базиса имеет школьный курс математики, крайне тяжело научить императивному программированию.
Потому что он не имеет никакого опыта работы с "абстрактным вычислителем".
По моему опыту работы с непрофильными студентами первых курсов, концепции "переменной" вызывают значительный баттхёрт.
Просто потому, что в школе x = 2 + a и x — a = 2 — одно и то же, и этому обучают пять лет подряд.
А в программе внезапно оказывается, что x — это не символ, а имя ячейки, в которую можно что-то положить, а потом забрать.
И что положить в холодильник слона можно только за четыре инструкции, потому что сначала нужно достать оттуда жирафа.

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

После того, как вы объяснили людям указатели, вы пытаетесь дать им рекурсию, и начинается взрыв мозга, потому что x теперь одновременно хранит несколько значений. И вам нужен стек, и ещё много всего.

Да, в итоге на некоторых из жертв снисходит озарение, и картинка внезапно складывается.
Но к моменту, когда это произошло, их одноклассники, посаженные за Excel, уже не только освоили декларативное программирование, а наколбасили на нём тонны прикладных решений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.10.12 10:55
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>>>Что-то я перестаю понимать что ты имеешь ввиду под "абстрактной вычислительной моделью" Может расскажешь?

I>>>машина тьюринга — абстрактная модель. В ней нет никаких value-type и тд и тд.
G>>CLR тоже абстрактная модель.

I>CLR относительно машины тьюринга вполне конкретная.


А причем тут машина тьюринга? Для написания программ, работающих на CLR нужно знание\понимание машины тьюринга? У меня куча обратных примеров.

G>>>>Вот вычислительная модель CLR абстрактна, в том смысле что конкретной реализации нет. Лямбда-исчисление тоже абстрактно. При некоторых ограничениях эти модели дают одинаковый результат. При этом модели сильно разные. Чему ты предлагаешь обучать?


I>>>Начинать с обычного императивного программирования и формировать нужные абстракции. Дальше можно и лямбда счисление и CLR и все что угодно.

G>>А почему бы не начать с лямбда-исчисления? Ведь начиная с него надо гораздо меньший путь пройти до map\fold, а с ними уже можно написать реальные программы.

I>Потому что лямбда-счисление это очень высокоуровневая абстракция.

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

I>Пойми простую вещь — математику осваивают с палочек.

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



I>Например зная ВМ весь школьный курс можно уложить примерно в страничку текста. Это значит, что страничку текста освоить на порядки сложнее, чем проштудировать 10 учебников и задачников.

ВМ опирается на школьный курс, лямбда исчисление не опирается на машину тьюринга. Подумай над этим.
Re[13]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.10.12 12:30
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Не смеши людей

G>>Это к чему? У тебя другое мнение? Аргументировать можешь? Я рекурсивные функции могу за 2 часа объяснить. ФВП еще за час. Рекурсивные структуры данных — тоже два часа.

I>Верю. А за какое время студенты смогут освоить все это до уровня свободного владения ?

Если голый рассказ дополнить практикой в том же объеме, то достаточно. По универским метрикам — 5 теоретических и 5 практических занятий будет достаточно.

G>>Причем я все это делал. Как ты думаешь, долго еще до map? Без углублений в теорию и типы данных это все очень простые концепции, в разы проще чем МТ.

I>Объяснения не интересуют. Важно время на то, что бы попробовать все вещи руками, то есть, освоить вычислитель, что бы более менее адекватная моделька сложилась в голове.
Как ты собрался МТ руками пробовать? Я не пойму о чем ты.

G>>Да-да, я как раз об этом и говорю. Для того чтобы ездить мне все это не надо знать. Надо только понимать что двигатель соединен с колесами и как работает сцепление.

I>Ну то есть этого знать не надо, но только это и надо понимать. Опаньки !
Нет, всего остального знать не надо, да и это необязательно.

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

G>>Совершенно необязательно. У меня куча контр-примеров. Люди много лет ездят и не знают что такое подшипник.
I>Термина вполне возможно и не знают.
Конструкции и подавно

G>>Че? Ты в автошколе давно был? Там гораздо примитивнее объясняется, и то этого много. При наличии всяких ABS и автоматических коробок передач вообще не надо знать устройства автомобиля.

I>Ты вероятно думаешь, будто я утверждаю, что надо знать устройство не хуже автомеханика или вообще конструктора ?
Я слабо понимаю что ты утверждаешь, но я утверждаю что для вождения современного автомобиля вообще не надо знать его устройство.
Re[17]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.10.12 13:02
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Я не предлагаю начинать учить програмимрованию в 3м классе. Что касается примернов, то про 3й клас у меня он единственный да. А вот люди, которые начинали в 4-6м встречается на собеседованиях относительно часто.

Тогда зачем вы постоянно сбиваетесь на то, что для ФП нужны концепции, которые начинают изучать в пятом?

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

I>Доказательство простоты имерератива тривиальное — дошкольники уже понимают как пользоваться инструкциями, то есть выполнять. Школьники уже умеют их составлять. Все, это означает что в самом императиве нет никакой сложности. Собтсвенно о чем я говорю уже наверное вторую неделю.
Вы вторую неделю повторяете бездоказательные утверждения, периодически приплетая цитаты из сомнительных работ из совершенно другой науки.
Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит. Зато "подставлять выражения в формулу" они у вас же не умеют, несмотря на то, что их этому учат с 5го по 11й класс.
I>Я наблюдаю вагоны программистов в разных организациях которые не знают и не желают приобщаться к функциональщине и при этом им почему то платят деньги.
А я знаю несколько тысяч людей, которые говорят по-русски. И ни одного, кто свободно бы владел эсперанто.
Я правильно понимаю, что это доказывает сравнительную сложность изучения эсперанто по сравнению с русским языком?
На всякий случай напомню, что мы обсуждаем не относительную численность программистов на разных типах языков, а пологость кривой обучения.
I>А почему вдруг они стали непрофильными ?
Потому что они изучали математику, а программирование для них — неинтересный спецкурс.

I>Я думаю дело в подходе к обучению.

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

I>Преподаватели. Императив требует тоже самое что и функциональщина и программирование вообще — освоение вычислителя.

ФП не требует никакого освоения вычислителя. По крайней мере, на начальных этапах.

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

Отличная задача по электротехнике. 99% знакомых мне императивных программистов провозятся не один месяц над решением этой задачи.
Потому что тут вопрос не в программировании, а в математике

I>Нужен, не боись, это не я придумал.

А, ну тогда не вам дадут премию Тьюринга. Теорему Чёрча не каждый день опровергают.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 10:37
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

S>>Концепция совершенно другая. Вам уже пять раз в этом топике указали на то, что императивное программирование не бывает без переменных и instruction pointer. А вы продолжаете долбить чушь, принимая декларативные утверждения типа "табуретка состоит из сиденья и ножек" за императивную программу по сборке табуретки.


I>Скажу страшное — твой пример это ассертивное утверждение, а не императивное.


Императивное это будет так — "ножки прикреплены к сиденью".
Re[59]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 11:01
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>Если человек не понял, то это означает, что ты объяснял понятиями которые отсутствуют у этого человека.

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

Напомню вам анекдот: "как работает автомат? Очень просто: раз-два-три и вас нет!".
Это — прекрасная иллюстрация того, что информация о внутреннем устройстве не является необходимой.
Достаточно знать наблюдаемое поведение.
Вы можете сколько угодно развлекать себя изучением внутреннего устройства гидроусилителя тормозов — это ничего вам не даст, как пользователю, по сравнению с моделью "сильнее давишь — шибче тормозит". Особенно если вы водите машину с электронными тормозами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 11:55
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

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

S>А чего тут опровергать? 99.5% современных водителей понятия не имеют о том, как работает двигатель, трансмиссия и рулевое управление в их машине. Вообще никакого понятия.

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

Если не понятно, то еще раз — нигде.

На всякий, в третий раз только в этом сообщении — нигде.

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

P.S. Если ты и сейчас хочешь сорвать покровы на тему "водитель не имеет понятия", то лучше не пиши ничего, а то я начинаю сомневаться, что ты умеешь читать.
Re[25]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 12:00
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

I>>Императивное это будет так — "ножки прикреплены к сиденью".

S>Это по-прежнему декларативное утверждение, сколько бы вы его ни крутили. Это — не инструкция по сборке табуретки. Это констатация факта: существует механическая связь между ножками и сиденьем.

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

S>Императивная инструкция по сборке будет оперировать изменяемым состоянием.


Правильно.

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


А переменные это специфика конкретного вычислителя, например машины тьюринга. Если под вычислителем будет выступать сам человек, то ему не надо никаких переменных вводить, ибо работать с изменяемым состоянием он умеет почти что "искаропки".
Re[66]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 10:34
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

I>>Возможно у тебя очень хороший автос и тебе не приходилось ни с чем сталкиваться

S>Отлично, так и запишем: знания подробностей внутреннего устройства нужно для плохих реализаций.

Знания подробностй нужны для реального мира. В идеальном мире нужна только функция перемещения из А в Б. Да и то это не полностью идеальный мир ибо в абсолютно идеальном мире незачем куда либо перемещаться.

Если рассмотреть наиболее продвинутые вещи, с которым имеет дело человек, например тот же самый нож, то окажется и здесь надо знать кучу нюансов даже если нужно чтото навроде "отрезать кусочек хлеба".
Re[71]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.12 13:18
Оценка: -1
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Сложнее, т.к. это абстракция более высокого уровня.


G>>Абстракция более высокого уровня проще.


I>Ну, давай по кругу — давай сразу интеграл что бы задачи на площать считать. Раз абстракия проще,значит никаких проблем с освоением быть не должно. В каком классе начинают считать задачи на площать ?


Сумма для вычисления площади прямоугольника — абстракция над операцией интегрирования, скрывает ненужные детали.

G>>Так вот в применении for гораздо сложнее map


I>Для кого сложнее ? Если человек только что сел за программирование, у него нет в голове такой абстракции, как map, а задачи скажем на обработку последовательностей он вообще не решал. for для него это одна из самых первых абстраций, когда он уже попробовал инструкции и ветвления.


Ну так надо изучать последовательности. Потому что большая часть реальных задач сводится к обработке последовательностей.
Re[18]: Императивное программирование
От: vdimas Россия  
Дата: 08.10.12 18:08
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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


Тут этим заняты 100% участников.

S>Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит.


Как это не учат, если даже решение квадратного уравнения даётся в школе как пошаговый алгоритм? К тому же, с ветвлением.

S>Зато "подставлять выражения в формулу" они у вас же не умеют, несмотря на то, что их этому учат с 5го по 11й класс.


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

I>>Я наблюдаю вагоны программистов в разных организациях которые не знают и не желают приобщаться к функциональщине и при этом им почему то платят деньги.

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

Нет, ты не понимаешь, что здесь идет сравнение некоего эсперанто-1 vs. эсперанто-2. И статистика показывает, что эсперанто-1 изучается быстрее/легче и от этого охотнее. А знаешь, что пишут во введении к 99% амеровских учебников? Что основная задача — это развить в студенте заинтересованность в предмете. Полностью согласен.

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


Ну так и надо давать сначала более простые темы. "Разрыв первого рода" м/у ФП и императивом наблюдается чаще всего у программистов без профильного образования. Из-за пробелов в основах. А ты предлагаешь, по-сути, эту непрофильность закрепить.

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

I>>А почему вдруг они стали непрофильными ?

S>Потому что они изучали математику, а программирование для них — неинтересный спецкурс.
I>>Я думаю дело в подходе к обучению.
S>А я думаю, что проще учить программированию постепенно, а не начиная с самых противоестественных для обычного человека концепций.

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


I>>Преподаватели. Императив требует тоже самое что и функциональщина и программирование вообще — освоение вычислителя.

S>ФП не требует никакого освоения вычислителя. По крайней мере, на начальных этапах.

ФП потребует понимания рекурсии уже на 3-м уроке по программированию, в отличие от простого цикла на 20 GOTO 10... Уууупс!!! Вот и приплызд, бо рекурсию многие студенты понимают дай бог спустя несколько месяцев начала обучения программированию. Что тут требовать от школьников?



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

S>Отличная задача по электротехнике. 99% знакомых мне императивных программистов провозятся не один месяц над решением этой задачи.

Мде? Ну тогда понятна твоя "любовь" ко всему императивному. Хотя, это лишний аргумент в пользу того, что императив могут освоить даже люди с недостаточными знаниями. Как раз дети/ученики/студенты автоматом попадают в эту категорию. То бишь, твой пример скорее о людях. Бо я, наоборот, не видел еще грамотных программистов, для которых мин-макс является откровением или занял бы месяцы на повторить/освежить.

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


S>Потому что тут вопрос не в программировании, а в математике


Гы-гы.... Из "математики" тут только две оптимизирующие ф-ии, которые тривиальны (для случая ребер 0-й физической толщины... в отличие от реальной трассировки соединений). А так-то мин-макс алгоритмы очень даже неплохо смотрятся в императиве. Более того, эти алгоритмы изначально объясняются как некая пошаговая стратегия. Опять ууупс? )))
Re[80]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 08:28
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

I>>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял


G>Ну не сливайся ты так. Ведь никто тебе не говорит что надо забыть C++ и писать на чем-то еще. Тебе ведь говорят что не надо на нем учить программировать, это вредно.


А я по твоему предлагаю С++ использовать для обучения ? Дай цитату.

G>Кстати обработка данных обычно декларативна. Самый массовый язык обработки данных — SQL — ни разу не императивен. Что ты имеешь ввиду под управлением ресурсами и вводом-выводом — непонятно.


Обычно императивный код даёт наилучший результат. SQL это массовый язык, только покрывает мизерную часть задач обработки данных. Ресурсы, ввод-вывод — самый простой пример это драйвера, ОС и тд.
Re[20]: Императивное программирование
От: vdimas Россия  
Дата: 09.10.12 08:45
Оценка: -1
Здравствуйте, gandjustas, Вы писали:

S>>>Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит.

V>>Как это не учат, если даже решение квадратного уравнения даётся в школе как пошаговый алгоритм? К тому же, с ветвлением.
G>Да ну? Что там сначала надо вычислять b^2 или 4ac ?

Садись, два. Перед ветвлением надо обязательно вычислить дискриминант квадратного уравнения.


G>И где там ветвление? Ветвление предполагает выбор одной из альтернатив, а у квадратного уравнения может быть два корня.


Опять два. Корней либо два, либо один, либо ни одного (оно же два мнимых). Ветвление идет по значению дискриминанта.

G>Приведи этот алгоритм на каком-либо императивном языке.


Сам справишься


S>>>Зато "подставлять выражения в формулу" они у вас же не умеют, несмотря на то, что их этому учат с 5го по 11й класс.


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

G>Ты не путай вычисления методом подстановки и символьные преобразования. Вторые аццки сложны, первые тривиальны.
G>При обучении композиции функций как раз требуются сложные символьные выражения.

Дык, ты читать умеешь? Я и не путаю, это Синклер изволит путать ровно противоположные по характеру навыки. Я лишь показываю, в чём путаница.

Тут как-то правильно сказали, что ФП имеет простую формулировку. Я бы дал совсем простую: "программа на ФП — это комбинация отображений". Всё! Кто понимает эту фразу, тот понимает, что такое ФП. Но блин, для понимания такого уровня абстракций надо 10 лет отучиться в школе и еще потом задеть крылом ту часть математики, которая уже относится к вышке. Т.е. простота формулировки вовсе не значит простоту понимания.


V>>Цимус ситуации, кстате, даже в том, что любое решение, даже будь оно сугубо в формулах, можно разложить на шаги/этапы. Т.е. на некую последовательность рассуждения. То бишь процесс вычисления ф-ий во времени вполне естественнен для понимания. Это даже можно показывать наглядно через отладочную печать или в каких-нить современных пакетах моделирования.

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

Не нагоняй страху. Разрыв происходит тогда, когда необходимо понять, что факт работы программы во времени мешает пониманию ФП. Я ведь помню, как трудно детям на первых порах понять, что если приложили напряжение к одному концу длинного провода, то при замыкании ток возникнет на другом конце мгновенно. Дети даже с трудом понимают, почему нельзя писать на провод — ведь "вода" течет от ребенка, как же ток так быстро бегает против течения??? )))

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

S>>>А я думаю, что проще учить программированию постепенно, а не начиная с самых противоестественных для обычного человека концепций.

V>>Эта твоя "противоестественность" надуманна как оправдание модному увлечению. А на деле оно приходит лишь с пониманием большого кол-ва вещей. Мыслить по-настоящему абстрактно человек умеет уже в достаточно зрелом возрасте. А чем меньше ребенку лет, тем больше рулит наглядность. Императив же нагляден по своей природе.
G>И что? Сравни формулу для вычисления корней и любую императивную запись его, посмотрим что нагляднее.

Формула для его вычисления ПОШАГОВАЯ. Только это и важно. Можно посмотреть результаты на каждом шаге. А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе. Ы-Ы-Ы.



V>>ФП потребует понимания рекурсии уже на 3-м уроке по программированию, в отличие от простого цикла на 20 GOTO 10... Уууупс!!! Вот и приплызд, бо рекурсию многие студенты понимают дай бог спустя несколько месяцев начала обучения программированию. Что тут требовать от школьников?

G>Рекурсия элементарна если использовать банальную подстановку. В 100500 раз легче goto.

Враки. Я говорю, то, что видел. Рекурсию многие понимали дай бог к концу первого семестра. А императивный цикл дается на 2-3-й лекции и понимается без проблем, даже девочками...

G>Более того многие вещи в математике рекурсивны по природе. Те же факториалы или числа Фибоначчи.


Они не рекурсивны, а итеративны. К тому же по вышке одновременно читают ряды, так что пошаговость-итеративность вычислений для получения X[i] = F(X[i-1]) — легко воспринимаемое императивное действо.
Re[21]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.10.12 10:03
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


S>>>>Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит.

V>>>Как это не учат, если даже решение квадратного уравнения даётся в школе как пошаговый алгоритм? К тому же, с ветвлением.
G>>Да ну? Что там сначала надо вычислять b^2 или 4ac ?

V>Садись, два. Перед ветвлением надо обязательно вычислить дискриминант квадратного уравнения.


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


G>>И где там ветвление? Ветвление предполагает выбор одной из альтернатив, а у квадратного уравнения может быть два корня.


V>Опять два. Корней либо два, либо один, либо ни одного (оно же два мнимых). Ветвление идет по значению дискриминанта.


Приведи этот алгоритм на каком-либо императивном языке.


V>Тут как-то правильно сказали, что ФП имеет простую формулировку. Я бы дал совсем простую: "программа на ФП — это комбинация отображений". Всё! Кто понимает эту фразу, тот понимает, что такое ФП. Но блин, для понимания такого уровня абстракций надо 10 лет отучиться в школе и еще потом задеть крылом ту часть математики, которая уже относится к вышке. Т.е. простота формулировки вовсе не значит простоту понимания.

Зачем понимание ФП? Композицию функций, рекурсию, ФВП можно объяснить очень быстро (несколько занятий). За счет простой модели вычислений.
Потом структуры данных, рекурсивные структуры данных и типовые алгоритмы.
Этого уже достаточно чтобы писать программы.

Для этого не нужно знать что "программа на ФП — это комбинация отображений".


V>>>Цимус ситуации, кстате, даже в том, что любое решение, даже будь оно сугубо в формулах, можно разложить на шаги/этапы. Т.е. на некую последовательность рассуждения. То бишь процесс вычисления ф-ий во времени вполне естественнен для понимания. Это даже можно показывать наглядно через отладочную печать или в каких-нить современных пакетах моделирования.

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

V>Не нагоняй страху. Разрыв происходит тогда, когда необходимо понять, что факт работы программы во времени мешает пониманию ФП.

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

Вообще "время" в программе не связано с реальным временем, оно связано с наблюдаемым состоянием программы.

V>Я ведь помню, как трудно детям на первых порах понять, что если приложили напряжение к одному концу длинного провода, то при замыкании ток возникнет на другом конце мгновенно. Дети даже с трудом понимают, почему нельзя писать на провод — ведь "вода" течет от ребенка, как же ток так быстро бегает против течения??? )))

Странные у тебя аналогии. Мы вообще-то не про детей говорим.

V>Тут аналогично — убрать из размышлений фактор времени будет очень болезненно без некоторого навыка оперирования абстракциями. Не отмахивался еще никогда от детских "почемучек"? Вот тебе начало: "а почему вычисляется мгновенно, а кто его вычисляет, а почему можно пренебречь, а что будет, если вычислять не сразу..." и т.д. до бесконечности. Императив же автоматом даёт ответы на любые "почему" своей простотой механики, сопровождаемой наглядностью.

А ты вообще пытался людям математику преподавать? Почему там никто не говорит про время? Большая часть ФП основана на чистой математике и не имеет отношения к конструкции конкретного вычислителя. Если ты сразу начинаешь с императивного вычислителя, то сталкиваешься со временем во всей красе.


S>>>>А я думаю, что проще учить программированию постепенно, а не начиная с самых противоестественных для обычного человека концепций.

V>>>Эта твоя "противоестественность" надуманна как оправдание модному увлечению. А на деле оно приходит лишь с пониманием большого кол-ва вещей. Мыслить по-настоящему абстрактно человек умеет уже в достаточно зрелом возрасте. А чем меньше ребенку лет, тем больше рулит наглядность. Императив же нагляден по своей природе.
G>>И что? Сравни формулу для вычисления корней и любую императивную запись его, посмотрим что нагляднее.

V>Формула для его вычисления ПОШАГОВАЯ. Только это и важно.

Это свойство самой формулы или того как ты эту формулу воспринимаешь?

V>Можно посмотреть результаты на каждом шаге.

Какие результаты?

V> А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе. Ы-Ы-Ы.

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



V>>>ФП потребует понимания рекурсии уже на 3-м уроке по программированию, в отличие от простого цикла на 20 GOTO 10... Уууупс!!! Вот и приплызд, бо рекурсию многие студенты понимают дай бог спустя несколько месяцев начала обучения программированию. Что тут требовать от школьников?

G>>Рекурсия элементарна если использовать банальную подстановку. В 100500 раз легче goto.

V>Враки. Я говорю, то, что видел. Рекурсию многие понимали дай бог к концу первого семестра. А императивный цикл дается на 2-3-й лекции и понимается без проблем, даже девочками...

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

G>>Более того многие вещи в математике рекурсивны по природе. Те же факториалы или числа Фибоначчи.


V>Они не рекурсивны, а итеративны.

Рекурсия — когда одинаковые символы встречаются в обоих частях выражений.

F(n) = F(n-1) + F(n-2)
Где тут итерация? Опиши последовательность действий для вычисления N-ого числа фибоначчи, докажи что она эквивалентна формуле.
Это крайне непростая задача.

V>К тому же по вышке одновременно читают ряды, так что пошаговость-итеративность вычислений для получения X[i] = F(X[i-1]) — легко воспринимаемое императивное действо.

Ну это ты самый простой случай описал. Лучше на примере размена монет напиши.
Re[4]: TMTOWTDI
От: vdimas Россия  
Дата: 10.10.12 17:54
Оценка: -1
Здравствуйте, Klapaucius, Вы писали:

I>>Для начинающего естественно использовать именно тот подход, которым он руководствуется в обиходе, например при покупкав магазине или при построении-реализации планов на отпуск и тд и тд и тд.

K>Ну, в обиходе используется арифметика, которая вообще-то декларативна.

Это вообще неважно. На бумажке или калькуляторе человек раскладывает вычисления на шаги.

I>>ни разу не видел начинающего программиста, которому хаскель зашел бы легче, чем Си. Количество кода в сортировке мало чего показывает.

K>А есть опыт сравнения обучения программистов, начинающих с С и с Хаскеля? Вопрос без подвоха, мне действительно интересен опыт, потому как сам я не знаю ни одного примера обучения программированию на хаскеле, как на первом языке.

Удивительно, не правда ли? ))
Re[6]: TMTOWTDI
От: vdimas Россия  
Дата: 10.10.12 18:07
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

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

S>Дело не в речи, а в способе описания алгоритмов.
S>На всякий случай напомню, что всё отличие императива — в наличии изменяемого состояния.

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

S>Характерным свидетельством декларативности повседневной деятельности является отсутствие циклов. Никто не думает о покупках или планировании отпуска в стиле "так, теперь увеличим номер текущего пункта на единицу, посмотрим, не больше ли он общего количества пунктов списка, и перейдём на шаг один".

S>Думают в стиле "так, мне надо купить масло, яйца, кефир, сметану и помидоры". В произвольном порядке — как увидел в магазине, так и взял.

Упс... и привел банальный цикл как пример отсутствия циклов. )))

Поведение покупателя в общем виде таково:
начало цикла:
  если список покупок не пуст
    ищем очередной товар в списке необходимых покупок
    если товар найден в списке
      берем товар
      вычеркиваем соотв. пункт из списка
    иначе
      переход на начало цикла
  иначе
    переход на конец цикла   
конец цикла:



S>А то и вовсе "о! у них акция на разливное пиво — возьму-ка я трёшечку".


Ну дык, никто не запрещает держать список в уме или формировать его на ходу. Просто это уже чуть более сложное поведение, где добавляются шаги по коррекции списка продуктов. Вот тебе твоё изменяемое состояние списка продуктов в полный рост.
Re[23]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 11.10.12 06:12
Оценка: -1
Здравствуйте, vdimas, Вы писали:

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

Полная чушь. Никакой фундаментальности тут нет.
Домашнее задание:
1. выяснить, как работает ускоренная схема арифметического сложения, понять, почему там аргументы вычисляются до предиката, а не после.
2. вывести граничные условия для случая, когда порядок вычисления аргументов функции ветвления обязан быть таким, как вы думаете, что он должен быть всегда.
3. найти случаи, в которых можно вообще обойтись без вычисления предиката.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: TMTOWTDI
От: vdimas Россия  
Дата: 11.10.12 15:36
Оценка: -1
Здравствуйте, Sinclair, Вы писали:

S>Замечательно. И что, вы полагаете, что реальные индивидуумы в реальной жизни действуют именно по этому алгоритму?


Угу, особенно если покупки делает сильная половина по заданию своей прекрасной половины. ))


S>Тогда я вас разочарую — нет, не действуют они по этому алгоритму. Реальный алгоритм там очень fuzzy, и включает массу неэффективностей и повторов.


Т.е. всего лишь чуть сложнее алгоритм, но суть та же. Человек не может осмотреть все продукты одновременно и одновременно принять все решения. Только пошагово.


S>И это при том условии, что у человека есть заранее подготовленный список покупок. Часто его нет, и покупки производятся исходя из программы типа "чего-нибудь на ужин".


Дык, поменяй предикат при if. Принципиально ничего не изменится.
Re[85]: Императивное программирование
От: vdimas Россия  
Дата: 11.10.12 19:36
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

S>>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать маломальски интересных инвариантов.


I>Ну ладно, с лотком ты прав


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

Говнодрайвер? — Да.
Виноват императив? — Нет, ес-но. Виноват говнопрограммер.

I>оконные менеджеры испокон веков писались на тормозах разных сортов и ни разу это не становилось проблемой


Вообще-то становилось. Ужасный линухово-юниховый гуй всегда был притчей во языцех. Зато у вынь и мак системный гуй всегда вылизан до идеальности в плане перформанса. В виндах состояние очереди сообщений к окошкам (к потоку, если быть точным) даже влияет на решения шедуллера.
Re[21]: TMTOWTDI
От: vdimas Россия  
Дата: 11.10.12 19:44
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

S>Иперативное программирование отличается от, скажем, функционального вовсе не тем, что оно "указывает, что делать". Оно оперирует изменяемым состоянием некоторого вычислителя. SQL, к примеру, тоже "императивен" в том смысле, что у него все стейтменты представляют собой глаголы в повелительном наклонении. Однако это никак не влияет на его декларативную природу.


Кстате, вот сам же себя только что опроверг, когда ты отрицал, что декларативность — это скорее взаимоотношение уровней абстракций, чем независимое св-во. В этом смысле UPDATE table из SQL точно так же декларативен как printf() в С++, потому что точно так же задаёт, ЧТО надо делать, а не КАК... Более того, не смотря на всю "чистоту" и "декларативность" каждого SQL-выражения в отдельности, последовательность SQL-выражений составляет несомненно императивную программу над состоянием базы. Как тут принято в последнее время — муахаха... ))
Re[86]: Императивное программирование
От: vdimas Россия  
Дата: 12.10.12 08:38
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

V>>Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))

S>А ещё все программы на десктопе исполняются вообще одним и тем же процессором с одной и той же системой команд, и она, естественно, императивна.
S>Этого достаточно, чтобы понять, почему ваш аргумент не имеет в данном контексте никакого смысла, или нужно разжевать?

Кстате да, нужно разжевать.
1. Предложить архитектуру вычислителя, заточенную под ФП (алу, память и особенно интересует непротиворечивый ввод/вывод, работающий во времени);
2. Пояснить, почему когда речь об юзер-левельной программе на ЯВУ, тебя вообще интересует архитектура процессора? Ты ж сам многократно утверждал, что для ФП доступно больше анализа/оптимизаций.

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


V>>Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.

S>И здесь вы опять путаете тёплое с мягким, т.е. формулировку задачи с её решением.

Да нет, я лишь напоминаю, как именно решаются задачи в императиве и почему именно так. А то вы что-то много изобретать последнее время изволите того, чего реально нет и не предвидится в ближайший пару десятков лет как минимум. А на деле мне регулярно приходится разрабатывать высокоскоростные in-memory хранилища и АПИ запросов к ним на императивном языке. Дык, я же прекрасно вижу, что когда речь о заведомо определённой структуре данных, то у декларативного SQL нет никаких преимуществ.... Т.е. вообще никаких — одно сплошное неудобство в плане сопряжения с остальной программой + лишние накладные расходы для этого. К тому же, напрочь отрубается любая статическая оптимизация запросов (всё на инлайнах и шаблонах, ес-но).

В общем, для какой-нить консоли админа базы SQL хорош, сугубо для REPL, но для современной программы это заведомо чужеродный элемент. Отсюда и выплывают такие уродцы, как Hibernate или LINQ, лишь бы не SQL.
Re[27]: Императивное программирование
От: artelk  
Дата: 15.10.12 07:12
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


A>>Вот, кстати, скажи, здесь есть пошаговость:

A>>
A>>abs(x) { if x<0 -x else x }
A>>

A>>?

V>Есно, ты можешь внутри ф-ии добавить отладочную печать непосредственно перед предикатом и после захода в любую из веток, и всегда будешь получать одну и ту же упорядоченность

Мы обсуждаем, является ли оператор ветвления пошаговым в ФП. В примерах, конечно же, приводится код на чистом функциональном языке, а не на императивном, где, в частности, отладочную печать можно вставить в любую точку программы.
V>(даже если добавишь её через какой-нить хак, то бишь даже если заставишь компилятор думать, что твоя отладочная печать идет без побочных эффектов).
Естественно, хаки не рассматриваем.

A>>А тут:

A>>
A>>abs(x) { 
A>>  def b = (x < 0) :> int; // Cast
A>>  b*(-x) + (1-b)*x 
A>>}
A>>

A>>?

V>А тут итоговое выражение вычисляется в произвольном, недоступном тебе, порядке.

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

V>Ты показал правильный пример. Например, я всегда пишу здесь, что ветвление зло для современных процов, поэтому где можно, ветвления необходимо заменять вычислениями (как ты показал) или даже +1 косвенностью (например, виртуальный вызов в ООП или паттерны поведения, для ФП — лямбды и прочие Ф). Хотя, с косвенностью надо быть внимательнее со сценариями, т.к. при распространении констант ветвление иногда нивелируется еще на этапе компиляции, то бишь предикат исчезает, а +1 косвенность — нет... но это уже дело десятое, главное понимать, что проблема с ветвлением реально существует на современной аппаратуре.

Производительность ветвлений на современной аппаратуре не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.
Re[28]: Императивное программирование
От: vdimas Россия  
Дата: 15.10.12 08:42
Оценка: :)
Здравствуйте, artelk, Вы писали:

A>Здравствуйте, vdimas, Вы писали:


V>>Здравствуйте, artelk, Вы писали:


A>>>Вот, кстати, скажи, здесь есть пошаговость:

A>>>
A>>>abs(x) { if x<0 -x else x }
A>>>

A>>>?

V>>Есно, ты можешь внутри ф-ии добавить отладочную печать непосредственно перед предикатом и после захода в любую из веток, и всегда будешь получать одну и ту же упорядоченность

A>Мы обсуждаем, является ли оператор ветвления пошаговым в ФП. В примерах, конечно же, приводится код на чистом функциональном языке, а не на императивном, где, в частности, отладочную печать можно вставить в любую точку программы.
V>>(даже если добавишь её через какой-нить хак, то бишь даже если заставишь компилятор думать, что твоя отладочная печать идет без побочных эффектов).
A>Естественно, хаки не рассматриваем.

Увы, хаки тебе будут нужны для реального эксперимента. В чем заключается хак — уже написал.

A>>>А тут:

A>>>
A>>>abs(x) { 
A>>>  def b = (x < 0) :> int; // Cast
A>>>  b*(-x) + (1-b)*x 
A>>>}
A>>>

A>>>?

V>>А тут итоговое выражение вычисляется в произвольном, недоступном тебе, порядке.

A>А что мешает первому случаю быть синтаксическим сахаром для второго? Невычисление одной из веток будет всего лишь оптимизацией.

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

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

Кароч, я тут уже говорил как-то, что со временем ФП будет не особо нужно, бо компиляторы будут сами находить скрытые ошибки императиве, как это сегодня делает тулзина Valgrind, например. Смотри в суть вещей — ФП языки нужны сугубо как костыль для тупых компиляторов образца до начала ~2000-х годов. После этого наступили такие времена, что ведущие компиляторы с того же С++ стали частично суперкомпиляторами и "понимают" намного больше семантики (совершая в итоге намного больше преобразований) чем все компиляторы со всех ФП-языков вместе взятые. Скомпиленную программу на С++ при включенной оптимизации уже давно фактически нереально отлаживать пошагово, бо происходящее не соответствует написанному в исходнике.


A>Производительность ветвлений на современной аппаратуре не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.


Да ради бога. Я лишь одобрил попытку убежать от if. Жаль, что подобных преобразований немного. Просто ты привел такой пример, который тянет на исключение, хотя бы потому, что многие процы умеют сразу abs(x) как для целочисленных, так и плавающих чисел.
Re[31]: Императивное программирование
От: artelk  
Дата: 15.10.12 14:11
Оценка: +1
Здравствуйте, vdimas, Вы писали:

A>>Прекрасно, а чем if не функция?

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

A>>Ну тогда и "необходимо иметь уже вычисленный аргумент-предикат" так же попахивает непониманием. Нет никакой такой необходимости после подстановки символов.

V>Это только если предикат оперирует compile-time данными и может быть вычислен в compile-time.
Нет, не только.

V>Боюсь, "пошаговость" на одном только if не даст той наглядности, о которой исходно была речь.

V>А так-то да, ФП эмулируется на регистровых современных архитектурах. А даже предложенная для ФП data-flow архитектура вычислителя, упс... тоже упорядочивает вычисления на if.
V>

V>Основополагающим понятием потоковых (Dataflow) вычислений является принцип готовности к выполнению (ГКВ) операции по условию готовности всех необходимых для выполнения этой операции операндов. Операнд считается «готовым», если соответствующим этому операнду ячейкам памяти присвоено значение (вычислено ранее или константо-присвоено).

Детали реализации императивного вычислителя не имеют никакого отношения к вопросу о семантике оператора ветвления в ФП.

A>>Трассировка принадлежит к неязыковым средствам, обеспечивающим доступ к императивному вычислителю, эмулирующему ФП. Ее наличие не влияет на семантику языковых элементов, в частности оператора ветвления.

V>Да пофиг. Ты уже забыл с чего пошло обсуждение. Я высмеивал тот факт, что ФП ненаглядно, что наглядность достигается только через эмуляцию в императиве.
Для тебя.
V>Итого, сначала необходимо изучить императив, чтобы понимать происходящее в процессе эмуляции ФП.
Чтобы понимать происходящее в процессе эмуляции — да. Чтобы понимать ФП — нет.

A>>Функционального программирования не существует?

V>Agda2 пойдет? ))
В Agda2 нет паттерн-матчинга?
Re[33]: Императивное программирование
От: artelk  
Дата: 15.10.12 15:44
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Если if никуда не делся после подстановки всех символов, то его аргументы будут вычисляться в указанном мною порядке.

Но результат не зависит от порядка вычисления аргументов, что дает нам основание утверждать, что операция ветвления не является "пошаговой по свой природе".
Re[35]: Императивное программирование
От: artelk  
Дата: 16.10.12 15:50
Оценка: +1
Здравствуйте, vdimas, Вы писали:

A>>Но результат не зависит от порядка вычисления аргументов, что дает нам основание утверждать, что операция ветвления не является "пошаговой по свой природе".

V>Ты решил зайти на второй круг? )))
Так мы из первого не выходили пока.

V>А как насчет вычислимости ложной ветки? Так и не понял примера с факториалом?

uint fact(uint arg) {
  if(x < 2)
    return 1;
  else
    return arg * fact(arg - 1);
}

Тут выражение в первой ветке можно вычислить до предиката, а можно и после.

V>Ну хорошо... а как насчет корня из отрицательного числа? А как насчет деления на 0? Ведь реакция вычислителя в процессе вычисления должна сильно разниться для правильной и ложной веток в твоей умозрительной системе.

"Значением" ветки будет (_|_). Если потом, после вычисления предиката, будет выбрана вторая ветка, значение всего выражения будет определяться ей.
Re[32]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 10:03
Оценка: :)
Здравствуйте, artelk, Вы писали:

A>Очень интересно. Т.е. если в качестве предиката было бы (x>1), то второй пример потерял бы свою функциональную чистоту?


Если честно, забодал подменой темы обсуждения. Речь была о упорядочивании вычислений, а не о чистоте. 99% ф-ий в современном императиве тоже чисты и что с того? Императива не существет?

Целью-то (если подняться на самый верх противостояния ФП vs императив) является исключительно ссылочная прозрачность, которая, в свою очередь, гарантирует детерминированность. А иммутабельность/чистота ФП — это ни разу не цель, но одно из ср-в достижения цели. Не самое удобное ср-во, как по мне. Слишком дорого за него платить. Есть и другие способы.

В общем, если вернуться к цели обсуждения, то, прежде чем изучать ограниченные техники, навроде ФП, надо иметь четкое представление, зачем эти техники нужны. То бишь, что именно программист получит взамен столь высокой платы. А если человек плавает в св-вах чистоты, не понимает ссылочной прозрачности, умудряется рассуждать об вычислениях веток "раньше" во времени (!!!) когда речь об ФП, то это просто отдача дани ФП-моде и профанация в итоге.
Re[40]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 14:34
Оценка: :)
Здравствуйте, samius, Вы писали:

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

S>Да, с формулами сложновато, если они не содержат условных операций.

ЧТД.
Дать ссылку на определение СП?
Опять помусолим, насколько близки ФП и СП? )))

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

V>>Ээээ... меня-то не смущает. Но спор этот начался от того, насколько ФП близко к структурному программированию. Напомню, что основные бодания были вокруг циклов и ветвлений.

S>Спор был не о том, насколько близко, ведь меру никто не предложил пока. Спор был о том, происходит ли ФП от СП. Ты доказывал что происходит. Т.е. речь была не о степени близости, а о факте происхождения.

Тебе не стыдно, положив болт на один из своих предыдущих аргументов, тут же выдвигать какой-то новый? ))

Я не могу точно знать кто от кого произошел в теории, ес-но, хотя бы потому, что речь о практических парадигмах (лямда-исчисление и ФП-парадигма — это не совсем одно и то же). К тому же, вложение областей видимости в СП (основа основ СП) — это один-в-один вложение лямбд без явно объявленных связываемых аргументов (вспомни споры о "замыканиях" в Паскале). Именно так. Просто, коль речь о практических парадигмах в программировании, то СП утряслось в языках раньше чистого ФП. Более того, все первые ФП-языки относились скорее к СП-языкам, у которых дополнительно к СП появились ФВП (например, Lisp, APL, ML).


V>>>>Почему происходящее в ветвлении в ФП и СП одинаково — тоже показал не раз. Даже с учетом ленивости.

S>>>Раз 10 тебя просил показать мне пользу императивного оператора if с чистыми ветками, пользу императивного цикла с чистым телом. Увы...
S>>>Могу еще попросить показать пользу от последовательности чистых стейтментов. Уверен что кончится тем же.

V>>Сформулируй "пользу".

S>Пусть будет влиянием на значение результата вычислений. Но не время, такты процессора и т.п.

Дык, сто раз показывал. Мутации локально-видимых данных всегда чисты.
// Чистая императивная ф-ия
int sum(int a, int b, int c) {
  a += b;
  a += c;
  return a;
}

// еще
int abs(int x) {
  int y;

  if(x < 0)
    y = -x;
  else
    y = x;

  return y;
}

// еще
uint fact(uint x) {
  uint y = 1;

  for(uint i = 1; i < x; i++)
    y *= i;

  return y;
}


Специально расписал на промежуточных мутабельных переменных, чтобы показать, что мутабельность не значит отсутствия чистоты вычислений. Я тебе ссылку на определение чистоты вычислений уже давал, помнится.



V>>Почему переспросил? Тут некоторые считают (и где-то правы), что введение промежуточных иммутабельных переменных и выражение вычислительного потока с помощью последовательности независимых (на каждом шаге) вычислений с участием этих иммутабельных переменных вполне себе ФП.

S>Что-то я не понял, о чем речь. Можешь на пальцах?

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



V>>Дык, твою "пользу" вполне можно получить на самом последнем шаге, при подаче целевых таких вычисленных "переменных" куда-нить в "мир" в конце цепочки вычислений.

S>Я тебя прошу показать пользу условного оператора с чистыми ветками, либо цикла с чистым телом, либо сиквенса с чистыми стейтментами. Как они могут влиять на результат вычислений, кроме нагрева атмосферы?

Могут...
Теперь понимаешь, почему я занимаюсь просветительской деятельностью тут? )))
ФП стало слишком модным, многие в него подавшиеся не совсем отчетливо понимают, о чем идёт речь и для всё это было надо.


V>>Не подменяй тему. Я утверждал лишь, что оно есть, и что на это можно полагаться. Я ни разу не считал это проблемой. Просто это опять на руку мне, что любые наблюдаемые вычисления могут идти лишь в таком же самом порядке, как в СП.

S>Что такое наблюдаемые вычисления в отношении к ФП? Если ты о действиях императивного вычислителя, то иди лесом.

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


S>>>Про автоматическое распараллеливание вообще забей, оно не имеет отношения к обсуждению.


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

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

Не надоело подставляться?


V>>Ты не понял про интерпретацию памяти. См. что есть алгебраический тип данных. Если в процессе ПМ происходит "распаковка" абстрактного типа и затем участвуют "распакованные" значения конкретных типов, то на ПМ сразу появляется жопа вместо распакованных значений, потому что аргумент ПМ еще неизвестен.

S>Условие if-а тоже неизвестно, так что жопа может появиться в любой из 2х его веток, даже возвращающих константы.

Может, ес-но. А может и нет. А в ПМ всегда жопа, когда есть зависимость от результата распаковки абстрактного типа.

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

S>тут я не понял

Ну дык не все ветки ПМ юзают распакованные значения. Как крайний случай — смотри ПМ по некоему enum. Там простое ветвление, как на if.
Re[37]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.10.12 11:59
Оценка: +1
Здравствуйте, vdimas, Вы писали:
V>К сожалению, это унылый хак системы типов, нарушающий всякую чистоту ФП. При таком раскладе чистое ФП не существует, ты прав. )))
Это не хак системы типов. Это иллюстрация того, что сам вопрос "в каком порядке вычисляет ветки декларативного if-а императивный вычислитель" лишён смысла.

Это то же самое, что требовать перевести на русский язык английское слово "the".

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

Это легко продемонстрировать даже на императивном компиляторе — попробуйте посмотреть, сколько раз вызовется вычисление предиката в простой С++ программе, скомпилированной в релиз:
uint fac(uint n)
{
  return (n < 2) ? 1 : n * fac(n - 1);
}

int main()
{
   std:cout << fac(5);
}

Магия, благодаря которой это работает, называется SSA — single static assignment, и фактически означает перевод императивного кода обратно в функциональный. Ровно там же и заканчивается её могучесть — метаданных про чистоту функций в языке не предусмотрено, поэтому компилятор способен на такие подвиги только очень локально.
В бескомпромиссном ФП и так известно, что все функции — чистые, так что простор для подобных оптимизаций полностью открыт.
В частности, императивная версия функции fac(), построенная компилятором, вполне может выглядеть вот так:
uint fac(uint n)
{
  static const int[] values = {2, 6, 24, 120, 720, 5040, 40320, 362880, 39916800, 479001600};
  if (n > 12)
    throw new IntegerOverflow();
  else
    return values[i];
}
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[38]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 18.10.12 14:09
Оценка: :)
Здравствуйте, artelk, Вы писали:
A>Вот, еще реализация придумалась:
A>

    A>
  1. Запускаем 2 потока для веток
    A>
  2. Ждем случайное (например, в интервале [0, С1+arg*С2]) количество тактов процессора
    A>
  3. Вычисляем предикат
    A>
  4. В зависимости от значения предиката, останавливаем поток ненужной ветки (если он еще работает)
    A>
  5. Ждем поток нужной ветки (если еще не отработал)
    A>
  6. Берем результат из потока нужной ветки и возвращаем
    A>
Более того, такая реализация может иметь реальный смысл — в частности, когда у нас стоит задача минимизировать латентность. В императивном коде страшно вычислять "неправильную" ветку, т.к. она может иметь катастрофические побочные эффекты. В декларативном — нестрашно. Если есть несколько аппаратно независимых потоков — пусть все и работают. Потом просто выкинем ненужный результат.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[39]: Императивное программирование
От: artelk  
Дата: 22.10.12 06:40
Оценка: +1
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


A>>А как же "2. Если предикат вычислен, то успешная ветка тоже обязательно будет вычислена."?

V>Ну дык константа и будет вычислена.
Т.е. первая ветка может быть вычислена до предиката.
V>"Нечего вычислять" там было в плане выч-ресурсов в сравнении с другой веткой.
И что это доказывает?

A>>Вот, еще реализация придумалась:

V>Поторопимшись.
Видимо. Нужно было начать с законов логики. Только боюсь, что их не удастся выразить в терминах битов/байтов/инструкций процессора и т.п., и они будут опять проигнорированы.

A>>Ждем случайное (например, в интервале [0, С1+arg*С2]) количество тактов процессора

V>Не можешь ты этого делать в SMP.
Какая разница?

A>>Берем результат из потока нужной ветки и возвращаем

V>Опять ты всё это не можешь без потери детерминированности.
V>Кароч, когда параллелишь руками, то ты сразу расчитываешь на недетерминированное поведение (даже лень перечислять всевозможные ситуации). А если речь о чистых ф-иях, то какое нафик недетерминированное?
Чё?

A>>Реализация с потоками решает проблему бесконечного зацикливания, однако не имеет предопределенной упорядоченности условного оператора.

V>Твоя реализация с потоками не работает.
V>- нельзя останавливать вычислительный поток извне ср-вами ОС, можно только через прикладные "ловушки". То бишь, код дополнительного (любого) потока должен содержать ссылку на уникальный контекст вычислений и постоянно проверять, что котекст не помечен как ненужный.
И что мешает его иметь?
V>- нет никаких гарантий (вообше никаких), что потребляющие ресурсы комбинаторно взрывающиеся ложные комбинации дадут хоть какой-то шанс отработать правильным веткам. В общем случае мощность мн-ва правильных путей исполнения на многие-многие-многие порядки меньше, чем мощность мн-ва неправильных. И чем дальше работают неправильные ветки, тем хуже становится это соотношение со страшной степенной скоростью.
И что?
V>В общем, смотреть до посинения на факториал и думать, что будет происходить на КАЖДОМ шаге в случае твоего варианта ветвления. Потом вспомнить, что реальных программах ветвление поразвесистей обычно, то бишь показатель степень поболе 2-х будет... Потом опять вернуться к моему вопросу насчет распределения выч. ресурсов. Мне как-то сложно представить в обозримом будущем (ближайшие много десятилетий), что на холостые ветки исполнения можно будет тратить на многие порядки больше ресурсов, чем на целевые. В это упираемся и я сразу же об этом спросил. И вопрос пока в силе.
Налицо ignoratio elenchi. Вопрос был о возможности, а не о производительности.
Re[40]: Императивное программирование
От: vdimas Россия  
Дата: 22.10.12 09:23
Оценка: -1
Здравствуйте, artelk, Вы писали:

A>>>А как же "2. Если предикат вычислен, то успешная ветка тоже обязательно будет вычислена."?

V>>Ну дык константа и будет вычислена.
A>Т.е. первая ветка может быть вычислена до предиката.
V>>"Нечего вычислять" там было в плане выч-ресурсов в сравнении с другой веткой.
A>И что это доказывает?

Что некритично. Нерекурсивные ветки вообще некритично параллелить, ес-но. Но это слишком частный случай для чистого ФП, где нет других механизмов кроме ветвления на ПМ и рекурсии.

A>>>Вот, еще реализация придумалась:

V>>Поторопимшись.
A>Видимо. Нужно было начать с законов логики. Только боюсь, что их не удастся выразить в терминах битов/байтов/инструкций процессора и т.п., и они будут опять проигнорированы.

Скорее ты слишком многое игнорируешь, чем наоборот. Ты пытаешься рассуждать настолько абстрактно (то бишь, упрощенно), что умудряешься отбрасывать детали, которые ключевые и не могут быть отброшены. Я же пытаюсь рассуждать с т.з. разработчика компилятора с некоего ФП-языка. И я, в отличие от, прекрасно понимаю, чем ФП-парадигма отличается от лямбда-исчисления. Отсюда все мои вопросы.


A>>>Ждем случайное (например, в интервале [0, С1+arg*С2]) количество тактов процессора

V>>Не можешь ты этого делать в SMP.
A>Какая разница?

Для сфероконей — никакая. А для реальной обстановки в IT вплоть до твоей смерти, как профессионала — разница оч. большая.

A>>>Берем результат из потока нужной ветки и возвращаем

V>>Опять ты всё это не можешь без потери детерминированности.
V>>Кароч, когда параллелишь руками, то ты сразу расчитываешь на недетерминированное поведение (даже лень перечислять всевозможные ситуации). А если речь о чистых ф-иях, то какое нафик недетерминированное?
A>Чё?

Ээээ... тебе тоже дать ссылку на определение чистоты вычислений? Или сам найдешь?


V>>- нельзя останавливать вычислительный поток извне ср-вами ОС, можно только через прикладные "ловушки". То бишь, код дополнительного (любого) потока должен содержать ссылку на уникальный контекст вычислений и постоянно проверять, что котекст не помечен как ненужный.

A>И что мешает его иметь?

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


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

A>И что?

Действительно... Подумаешь, NP-проблема в условиях конечного SMP-вычислителя.


V>>В общем, смотреть до посинения на факториал и думать, что будет происходить на КАЖДОМ шаге в случае твоего варианта ветвления. Потом вспомнить, что реальных программах ветвление поразвесистей обычно, то бишь показатель степень поболе 2-х будет... Потом опять вернуться к моему вопросу насчет распределения выч. ресурсов. Мне как-то сложно представить в обозримом будущем (ближайшие много десятилетий), что на холостые ветки исполнения можно будет тратить на многие порядки больше ресурсов, чем на целевые. В это упираемся и я сразу же об этом спросил. И вопрос пока в силе.


A>Налицо ignoratio elenchi. Вопрос был о возможности, а не о производительности.


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

Жгите еще, попкорном я уже запасся.

===================
Мне лень ждать твоей следующей итерации с уточнениями алогоритма, бо я уже примерно понял ход твоих рассуждений... Как только ты ограничишь "предпросмотр" чем-то более детерминированным, чем контроль одного выч. потока из другого, ты обнаружишь ту самую упорядоченность вычислений, о которой всё время шла речь. А торговля будет идти лишь о глубине "заглядывания вперед", которое (само это заглядывание) будет точно так же упорядочиваться скоростью вычислений предикатов основного потока. Очередное муахахаа.. )))
Re[49]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.10.12 15:52
Оценка: :)
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


V>>>По-моему, ты уже тупо троллишь... Я специально тебе показываю, что на мутабельных операциях можно получать pure-functions и прямо об этом говорю.

S>>Тупо троллишь ты. С тем что на мутабельных операциях можно получить pure-functions я даже не пытался с тобой спорить об этом. Я тебе твержу о том, что чистое выражение не имеет смысла в примитивах СП. А ты все про баню.

V>ОМГ.

V>1. Имеет смысл, ес-но. Например в С/С++: тернарный оператор, оператор присваивания, оператор "," (запятая) — все эти операторы имеют (могут иметь) значения. Т.е. многие вроде бы стейтменты легко сходят за выражения, даже если тип выражения — void. И да, ты можешь смело вместо if обсуждать тернарный оператор, бо он тоже допускает любые возвращаемые типы выражений своих веток, тот же void. Ууупс??? Забыл??? ))
Ты упустил из виду что возможности C/C++ очевидным образом выпирают из базиса СП. Такшта обсуждение тернарного оператора отменяется.

V>2. Еще раз черным по белому — я знаю, что ты хотел у меня спросить. Но на подобные дешевые провокации не пойду всё-равно, даже при наличии п.1. и кучи вариантов как следствие этого пункта, вокруг которых вполне можно было бы пободаться (ветки-то вполне могут быть независимы даже в императиве, угу).

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

V>Просто смысла в этой клоунаде нет. Вместо пытаток в течении 10-ка постов выдавить из оппонента "правильный" ответ на провокационный вопрос можно было сразу выложить на стол все карты — что именно ты хотел услышать и что заготовил в кач-ве своего ответа?

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

V>Просто ситуация на на самом деле такова, что:

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

V>2. лучшие оптимизаторы сегодня для императива, и эти оптимизаторы прекрасно сами видят все зависимости. Это тупым ФП-компиляторам зависимости надо указывать явно.

С оптимизаторами ты идешь лесом, объясняю который раз.

V>3. так что обсуждать стоит возможность подобного переупорядочивания скорее для императива, как следует из п. 1 и 2. Тем более, что ты довольствуешься самой малой возможностью (вероятностью) подобных переупорядочиваний. Дык, в императиве этих возможностей на сегодня реально больше, чем в ФП.

Увы, ты ошибаешься. Императив завязан на порядок побочными эффектами. А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.

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

Исчерпывающим я его не считаю. Ты поскипал неудобные вещи и отмазался своими обычными заблуждениями.
Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 20.09.12 16:07
Оценка:
http://dev.by/blog/67127#devcut1
http://learncodethehardway.org/blog/AUG_19_2012.html

А теперь перечислим концепции, с которыми нужно познакомить читателя, чтобы объяснить ему, как работают, соответственно, циклы .each и for. Начнем с .each:
1.Переменные
2.Массивы
3.Перечни (enumerables)
4.Наследование
5.Примеси и их связь с множественным наследованием
6.Передача и диспетчеризация сообщений
7.Вызовы функций
8.Блоки, передаваемые вызовам функций
9.Вставка переменных в блоки
10.Область видимости – в частности, при работе с блоками

Но это же просто бездна понятий, которые придется объяснять человеку, который порой еще даже не может найти, где у него Terminal, а тем более разобраться, что передается Enumerable из mixin с блоком... А мой метод – сначала научить читателя писать код, а потом уже добиваться его внимания и понимания. Именно поэтому пока что, по моему опыту, сложнее всего научить человека ООП, и это самая неподходящая вещь для абсолютных новичков.

А что насчет циклов for?
1.Переменные
2.Массивы
3.Оператор if
4.Команды перехода (goto или jump)

И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.

Re: Императивное программирование
От: batu Украина  
Дата: 20.09.12 17:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:
>Но это же просто бездна понятий, которые придется объяснять человеку, который порой еще даже не может найти, где у него Terminal, а тем более разобраться, что передается Enumerable из mixin с блоком... А мой метод – сначала научить читателя писать код, а потом уже добиваться его внимания и понимания. Именно поэтому пока что, по моему опыту, сложнее всего научить человека ООП, и это самая неподходящая вещь для абсолютных новичков.

I>А что насчет циклов for?

I> 1.Переменные
I> 2.Массивы
I> 3.Оператор if
I> 4.Команды перехода (goto или jump)

I>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.


I>[/q]

Я думаю массивы даже лишнее что бы объяснить императивную парадигму. Это структуры данных. А вот присвоения не хватает.
ООП это уже стиль программирования.. Не думаю что и ООП будет сложно объяснить начав с процедуры, затем функции.. затем класс..
И вообще что бы объяснять нужно самому твердо усвоить..
Re: Императивное программирование
От: b-3 Россия  
Дата: 20.09.12 17:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А теперь перечислим концепции, с которыми нужно познакомить читателя, чтобы объяснить ему, как работают, соответственно, циклы .each и for. Начнем с .each:

I> 1.Переменные
I> 2.Массивы
I> 3.Перечни (enumerables)
I> 4.Наследование
I> 5.Примеси и их связь с множественным наследованием
I> 6.Передача и диспетчеризация сообщений
I> 7.Вызовы функций
I> 8.Блоки, передаваемые вызовам функций
I> 9.Вставка переменных в блоки
I> 10.Область видимости – в частности, при работе с блоками
Ничего этого, на самом деле, не нужно.
Достаточно единственной концепции — map

Поясню:
1. Символ из .each не является примером переменной, потому что в норме не изменяется;
2. Массивы тут не при чём, поскольку обращения по индексу в .each не происходит;
3. Перечни (enumerables) тождественны спискам в данном контексте;
4-5. Наследование и примеси не имеют смысла, это способ реализации типа "перечисление" в конкретном ЯП.
6. Передача и диспетчеризация имеют к .each такое же отношение, как и скажем движение указателя стека;
7. Вызовов функций в приведённом примере кода нет (на уровне синтаксиса)
8. Блок, передаваемый вызову функции, также деталь реализации, которая для понимания не нужна
В сухом остатке имеем "область видимости", "метод" и "перечисление". Плюс нечто, применяющее метод к каждому элементу перечисления.

Сложно? Возьмите соседскую девочку и посмотрите, во что она быстрее вьедет. В for или .each.
Забанен с формулировкой "клинический дисидент".
Re[3]: Императивное программирование
От: Гест Украина https://zverok.github.io
Дата: 20.09.12 19:28
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Гест, Вы писали:


_>Например возьмём Питон (кстати, а почему его до сих пор нет в списке подсветки форума, хотя он явно популярнее всяких там nemerle?).


_>Императивный пример:

_>
_>a=[1, 2, 3, 4, 5]
_>for i in range(len(a)): a[i]=a[i]*a[i]
_>print a
_>

_>Функциональный пример:
_>
_>a=[1, 2, 3, 4, 5]
_>a=map(lambda x: x*x, a)
_>print a
_>

_>Ну и какой из этих двух примеров проще для восприятия школьником? ) Фиг знает уже...

_>Да, кстати, лично мне оба не нравятся и я предпочитаю третий питоновский вариант, через генераторы. Который кстати выглядит чем-то промежуточным:

_>
_>a=[1, 2, 3, 4, 5]
_>a=[x*x for x in a]
_>print a
_>



А, адеквтаное отображение именно ваших питоновских примеров:

# императивный:
for i in 0...a.size
  a[i] = a[i]*a[i]
end

# функциональный:
a = a.map{|e| e*e}


Аргументы применимы все те же, что и в моём предыдущем сообщении.
Re[2]: Императивное программирование
От: Sharowarsheg  
Дата: 20.09.12 20:54
Оценка:
Здравствуйте, Гест, Вы писали:

Г>Ох уж мне эти теоретики.


Г>Покажите школьнику


Вы бы еще hello world показывали.
Re[4]: Императивное программирование
От: alex_public  
Дата: 20.09.12 21:41
Оценка:
Здравствуйте, Гест, Вы писали:

Г>А, адеквтаное отображение именно ваших питоновских примеров:

Г>
Г># императивный:
Г>for i in 0...a.size
Г>  a[i] = a[i]*a[i]
Г>end

Г># функциональный:
Г>a = a.map{|e| e*e}
Г>

Г>Аргументы применимы все те же, что и в моём предыдущем сообщении.

Вот это уже достаточно объективный пример для дискуссии о сравнение понятности кода в императивном и функциональном стиле.

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

Поправка. Я не знаю тонкостей реализации Ruby, но подзреваю что второй вариант всё же выделяет дополнительную память. Соответственно если мы имеем дело с массивом не из пары чисел, а на гигабайт, то разница между стилями будет уже не только в понятности кода, но и в работе, что как бы сразу всё определяет.
Re[2]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.09.12 16:27
Оценка:
Здравствуйте, DarkGray, Вы писали:

DG>начинай сразу с объяснения машины тьюринга — там концепций еще меньше..


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

DG>ps

DG>Если серьезно — то необходимо не минимальное кол-во концепций, а возможность за минимальное кол-во усилий решить реальную задачу стоящую перед пользователем. На основе лишь концепций массив, переменная, if и goto — это сделать очень и очень непросто.

В общем случае нужно объяснять вычислительную модель.
Re[2]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.09.12 16:32
Оценка:
Здравствуйте, gandjustas, Вы писали:


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


Вообще то надо, разумеется для случая, если пользователь ЯП будет писать код самостоятельно а не набирать из книги рецептов.

G>Поэтому научив последовательностям (как они работают, а не как устроены) и each\map\fold\filter\flatmap\какие_там_еще_функции можно ожидать что человек таки напишет программу, такую что другой человек её поймет.


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

G>А вот если обучать массивам, goto, присваиваниям итп, полученная программа будет понята только компьютером, и то не факт что правильно.


примерно 90% вузов именно так и готовят, а оставшиеся 10% постепенно отказывается от того бреда что ты перечислил в пользу императивщины, пример — МИТ, Стенфорд. Опаньки !
Re[4]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.09.12 16:36
Оценка:
Здравствуйте, Гест, Вы писали:

Г>Просто у автора исходной статьи такая же инженерчанка, как у AlexRK — люди с таким типом мышления не давали бы прав водителям, которые не могут собрать-разобрать "Жигули" с закрытыми глазами. Поэтому мой первый пример они начнут объяснять с лямбд и функций высшего порядка.


Выйди на базар какой или просто послушай, как люди планируют скажем покупки или ремонт и тд и тд — императивщина чистой воды. Обычно это так: "Зайди в Соседи, купи молока, сыра, если не будет Рокфора, возьми Мацарелу, посмотри колбаски, если будут Охотничьи, возьми два десятка, прихвати два десятка яиц и если будет Очаково Черное, возьми две бутылки"
То есть, это люди так думают на родном языке, в чисто императивном стиле. Странно ожидать, что программировать они будут в каком то другом стиле.
Re[5]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.09.12 16:39
Оценка:
Здравствуйте, alex_public, Вы писали:

_>Ну что тут можно сказать (кстати с Ruby я не знаком)... Лично мне конечно ближе второй вариант (с одной поправкой — см. ниже). Но это естественно потому, что я хорошо знаком с функциональным стилем. Я не уверен что он бы мне более понятен в тот момент, когда я начинал изучать программирование.


Когда люди начинают программировать, у них в голове нет никаких абстракций-понятий. Адепты ФП занимаются обманом, не объясняя вычислительную модель заставляют гонять задачи до тех пор, пока в голове у обучаемого не сложится полная картина. Идея рабочая, разница только в том, какой процент студентов сможет освоить это дело.
Re[2]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.09.12 16:41
Оценка:
Здравствуйте, b-3, Вы писали:

b-3>Ничего этого, на самом деле, не нужно.

b-3>Достаточно единственной концепции — map

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

b-3>Поясню:

b-3>1. Символ из .each не является примером переменной, потому что в норме не изменяется;
b-3>2. Массивы тут не при чём, поскольку обращения по индексу в .each не происходит;
b-3>3. Перечни (enumerables) тождественны спискам в данном контексте;
b-3>4-5. Наследование и примеси не имеют смысла, это способ реализации типа "перечисление" в конкретном ЯП.
b-3>6. Передача и диспетчеризация имеют к .each такое же отношение, как и скажем движение указателя стека;
b-3>7. Вызовов функций в приведённом примере кода нет (на уровне синтаксиса)
b-3>8. Блок, передаваемый вызову функции, также деталь реализации, которая для понимания не нужна
b-3>В сухом остатке имеем "область видимости", "метод" и "перечисление". Плюс нечто, применяющее метод к каждому элементу перечисления.

b-3>Сложно? Возьмите соседскую девочку и посмотрите, во что она быстрее вьедет. В for или .each.


Проверил на задачах вроде "покупки в магазине". Решение задачи на естественном языке один в один переводится в for.
Re: TMTOWTDI
От: Roman Odaisky Украина  
Дата: 22.09.12 12:47
Оценка:
По-моему, основная проблема здесь — TMTOWTDI. Естественный язык обладает этим свойством (можно перефразировать: TMTOWTSI), поэтому и появляются идиомы (в особо запущенных случаях — кеннинги), и нужно изучать, что же идиомы обозначают и когда они уместны, а когда нет.

По определению, идиома в языке программирования возникает, когда есть несколько способов добиться желаемого, и один из них является более удачным. Нет лишних способов — нет идиом. Если при разработке языка ставить целью единообразие, и, например, имея each, не вводить for в язык вообще, то не будет и проблем с идиомами.

А императивность здесь ни при чём. Что естественнее для начинающего?
quicksort [] = []
quicksort (x:xs) = quicksort small_elements ++ [x] ++ quicksort large_elements
   where small_elements = [y | y <- xs, y <= x]
         large_elements = [y | y <- xs, y >  x]


template <class RAI> // специфичную для C++ магию старался минимизировать
void quicksort(RAI first, RAI last)
{
    if(std::distance(first, last) <= 1)
    {
        return;
    }

    RAI pivot = first;

    typename std::iterator_traits<RAI>::value_type const pivot_value(*pivot);
    std::iter_swap(pivot, last - 1);
    RAI new_pivot = first;
    for(RAI it = first; it + 1 != last; ++it)
    {
        if(!(pivot_value < *it))
        {
            std::iter_swap(new_pivot, it);
            ++new_pivot;
        }
    }
    std::iter_swap(new_pivot, last - 1);

    quicksort(first, new_pivot);
    quicksort(new_pivot + 1, last);
}
До последнего не верил в пирамиду Лебедева.
Re[3]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.09.12 02:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

G>>Поэтому научив последовательностям (как они работают, а не как устроены) и each\map\fold\filter\flatmap\какие_там_еще_функции можно ожидать что человек таки напишет программу, такую что другой человек её поймет.


I>Ожидать можно все что угодно, даже второго пришествия Христа. Нет гарантии, что это наиболее эффективный способ обучения.


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

G>>А вот если обучать массивам, goto, присваиваниям итп, полученная программа будет понята только компьютером, и то не факт что правильно.


I>примерно 90% вузов именно так и готовят, а оставшиеся 10% постепенно отказывается от того бреда что ты перечислил в пользу императивщины, пример — МИТ, Стенфорд. Опаньки !

Не знаю насчет того как готовит MIT и Стенфорд, а вот российсуие вузы крайне плохо готовят программистов.
Re[6]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.09.12 03:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, alex_public, Вы писали:


_>>Ну что тут можно сказать (кстати с Ruby я не знаком)... Лично мне конечно ближе второй вариант (с одной поправкой — см. ниже). Но это естественно потому, что я хорошо знаком с функциональным стилем. Я не уверен что он бы мне более понятен в тот момент, когда я начинал изучать программирование.


I>Когда люди начинают программировать, у них в голове нет никаких абстракций-понятий. Адепты ФП занимаются обманом, не объясняя вычислительную модель заставляют гонять задачи до тех пор, пока в голове у обучаемого не сложится полная картина. Идея рабочая, разница только в том, какой процент студентов сможет освоить это дело.


А зачем знать "вычислительную модель"? Тем более что она сильно зависит от языка.

Излишнее внимание к вычислительной модели приводит к тому что на собеседованиях по C# люди говорят что value-type это тип, который размещается на стеке.
Re[3]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 23.09.12 03:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, b-3, Вы писали:


b-3>>Ничего этого, на самом деле, не нужно.

b-3>>Достаточно единственной концепции — map

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


Потому что их учили массвам и циклам for
Re[4]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 07:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ага, давай еще формализовывать "эффективность обучения".

G>Умея работать с функциями и последовательностями можно написать большую часть программ. Зная for и массивы — увы нельзя.

Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.
Re[7]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 08:03
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Когда люди начинают программировать, у них в голове нет никаких абстракций-понятий. Адепты ФП занимаются обманом, не объясняя вычислительную модель заставляют гонять задачи до тех пор, пока в голове у обучаемого не сложится полная картина. Идея рабочая, разница только в том, какой процент студентов сможет освоить это дело.


G>А зачем знать "вычислительную модель"? Тем более что она сильно зависит от языка.


Для того, что бы писать код самостоятельно. Вычислительная модель завит конечно от языка, но неправильно связывать её с языком. Знаешь вычислительную моджель — сможешь решать задачи на её основе. Не знаешь — ищи рецепты в инете.

G>Излишнее внимание к вычислительной модели приводит к тому что на собеседованиях по C# люди говорят что value-type это тип, который размещается на стеке.


Твой пример показывает косяки в освоении инструмента. Люди которые вообще не интересуются value-type пишут на редкость тормозной и глючный код.
Re[2]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 08:08
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>А императивность здесь ни при чём. Что естественнее для начинающего?


Для начинающего естественно использовать именно тот подход, которым он руководствуется в обиходе, например при покупкав магазине или при построении-реализации планов на отпуск и тд и тд и тд.

Примеры я скипнул. Извини, ни разу не видел начинающего программиста, которому хаскель зашел бы легче, чем Си. Количество кода в сортировке мало чего показывает.
Re[4]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 08:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

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


G>Потому что их учили массвам и циклам for


Императивное мышление не получится отменить.
Re[5]: Императивное программирование
От: Roman Odaisky Украина  
Дата: 24.09.12 10:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.


Верно, но не потому, что оно каким-то образом естественнее для человека, а потому, что на низком уровне компьютер всё равно управляется на 100% императивными методами.
До последнего не верил в пирамиду Лебедева.
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 11:35
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

I>>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.


RO>Верно, но не потому, что оно каким-то образом естественнее для человека,


Это мышление более прокачано, чем другие виды. Можно проверить как люди решают бытовые проблемы или занимаются планированием. Можно даже посмотреть, как начинающие руководители отдают распоряжения.

> а потому, что на низком уровне компьютер всё равно управляется на 100% императивными методами.


Управление не требует императивщины. Императивщину требует мышление и текущий уровень развития технологий. Например аналогичная проблема есть в менеджменте, когда начинающий руководитель начинает отдавать приказы "каждой гусенице" подчиненного. Со временем это переходит на другой уровень "к времени Х занять точку А" или "уничтожить пулеметное гнездо Б"
Re[7]: Императивное программирование
От: Roman Odaisky Украина  
Дата: 24.09.12 12:24
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.

RO>>Верно, но не потому, что оно каким-то образом естественнее для человека,
I>Это мышление более прокачано, чем другие виды. Можно проверить как люди решают бытовые проблемы или занимаются планированием. Можно даже посмотреть, как начинающие руководители отдают распоряжения.
>> а потому, что на низком уровне компьютер всё равно управляется на 100% императивными методами.
I>Управление не требует императивщины. Императивщину требует мышление и текущий уровень развития технологий. Например аналогичная проблема есть в менеджменте, когда начинающий руководитель начинает отдавать приказы "каждой гусенице" подчиненного. Со временем это переходит на другой уровень "к времени Х занять точку А" или "уничтожить пулеметное гнездо Б"

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

«Для каждого элемента списка: вывести элемент, затем вывести запятую, если он не последний»

или

«Вывести элементы списка через запятую»?
До последнего не верил в пирамиду Лебедева.
Re[8]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 12:39
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Так ты же сам говоришь, что даже в некомпьютерных делах декларативный подход совершеннее. Почему бы не начать с него сразу?


Потому, что это это дается не просто так, а является результатом многолетнего приложения усилий. Привить абстракции сверху, просто объясняя на пальцах, ен получится.
Декларативная арифметика осваивается через императивный период — на пальцах, на палочках, счетах и тд и тд. Только после этого люди могут писать 2+2 и понимать, что же это означает.
Фокус в том, что чем сложнее концепции тем дольше этот самый императивный период по времени.
Re[5]: Императивное программирование
От: Roman Odaisky Украина  
Дата: 24.09.12 12:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Я видел слишком много людей, которые работая программистами, с большим трудом понимали это [map].

G>>Потому что их учили массвам и циклам for ;)
I>Императивное мышление не получится отменить.

«Сумма квадратов первых n нечетных чисел» — это императивное или декларативное построение?

-- Сумма     квадратов  первых n  нечетных чисел
-----------  ---------  --------  --------
foldl (+) 0 (map (^2)  (take n    [1, 3..]))

// А это как соответствует человеческому пониманию?
int s = 0;
for(int i = 0, x = 1; i < n; ++i, x += 2) // как бы не ошибиться на единицу
{
    s += x * x;
}
return s;

«Ответом на этот HTTP-запрос есть этот шаблон, заполненный такими-то данными» — где императивность?
До последнего не верил в пирамиду Лебедева.
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 12:49
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

I>>>>Я видел слишком много людей, которые работая программистами, с большим трудом понимали это [map].

G>>>Потому что их учили массвам и циклам for
I>>Императивное мышление не получится отменить.

RO>«Сумма квадратов первых n нечетных чисел» — это императивное или декларативное построение?


Декларативное. Но это только результат и нет ничего про организацию вычислений.

RO>
RO>-- Сумма     квадратов  первых n  нечетных чисел
RO>-----------  ---------  --------  --------
RO>foldl (+) 0 (map (^2)  (take n    [1, 3..]))
RO>

RO>
RO>// А это как соответствует человеческому пониманию?
RO>int s = 0;
RO>for(int i = 0, x = 1; i < n; ++i, x += 2) // как бы не ошибиться на единицу
RO>{
RO>    s += x * x;
RO>}
RO>return s;
RO>

RO>«Ответом на этот HTTP-запрос есть этот шаблон, заполненный такими-то данными» — где императивность?

В задаче для получения результата нужно организовать вычисления. Это совсем не то же самое, что и решать уравнения на бумаге. И осваивается эта деятельность как и все другие, с сенсомоторной стадии,по своей природе императивной.
Re[2]: TMTOWTDI
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.09.12 12:55
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>А императивность здесь ни при чём. Что естественнее для начинающего?

RO>
RO>quicksort [] = []
RO>quicksort (x:xs) = quicksort small_elements ++ [x] ++ quicksort large_elements
RO>   where small_elements = [y | y <- xs, y <= x]
RO>         large_elements = [y | y <- xs, y >  x]
RO>


RO>
RO>template <class RAI> // специфичную для C++ магию старался минимизировать
RO>void quicksort(RAI first, RAI last)
RO>{
..................
RO>


Ну это иллюстрация преимуществ встроенной библиотеки для работы со списками. Например, код на C++ вполне может быть и таким:

list list::sort() const
{
  if (empty()) return list();

  list small_elements, greater_elemets;
  for (size_t i=1; i<size(); ++i)
    if (items[i] >= items[0])
      greater_elemets += items[i];
    else
      smaller_elemets += items[i];

  return smaller_elemets.sort() + list(l[0]) + greater_elemets.sort();
}


Ну а так C++ вариант это все-таки сортировка по месту, да и там элемент по честному вытягивается из середины (чтобы не было падения производительности на почти отсортированных последовательностях). Так что изначально сравнивается оптимизированный код против неоптимального, и задается вопрос: а что понятнее???
Re[10]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 13:02
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Ikemefula, Вы писали:


I>>Декларативная арифметика осваивается через императивный период — на пальцах, на палочках, счетах и тд и тд. Только после этого люди могут писать 2+2 и понимать, что же это означает.


RO>Счеты — не компьютер, а только средство хранения данных. Оно не проделывает действия. А 2+2 — это как раз квинтэссенция декларативности, это выражение не подразумевает никакого действия само по себе (да, я помню термин «арифметическое действие»). Может, у Васи было два яблока и ему дали (действие) еще два, а может, у него было два в одном кармане и два в другом. 2+2=4 — это не «x = 2; x += 2; assert(x == 4)», это не переход объекта из состояния «2» в состояние «4» под воздействием чего-то, что увеличивает его на 2, а просто математический факт. Пусть требуются определенные действия для того, чтобы выяснить, чему же равняется x, если x = 31415926 + 27182818, но главное же не сами действия, а результат.


Разумеется, результат. Что бы ребенок понял, что стоит за формулой 2+2 ему надо целый год перекладывать палочки. Минуя эту стадию не удастся получить понимаения такой абстаркции как арифметика.
Re[7]: Императивное программирование
От: Roman Odaisky Украина  
Дата: 24.09.12 13:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>В задаче для получения результата нужно организовать вычисления.


Именно. Компьютер-то императивный внутри.

Но если используемый язык достаточно умен для того, чтобы мы ему сказали, чтó нам надо, а он чтобы сам организовал, как этого добиться, почему так и не сделать?

Мы же пишем всё время z = x + y, а процессор на самом деле делает z = x; z += y. Это же не повод так и писать самим.
До последнего не верил в пирамиду Лебедева.
Re[3]: TMTOWTDI
От: Roman Odaisky Украина  
Дата: 24.09.12 13:17
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Ну это иллюстрация преимуществ встроенной библиотеки для работы со списками. Например, код на C++ вполне может быть и таким:


M>
M>list list::sort() const
M>{
M>  if (empty()) return list();

M>  list small_elements, greater_elemets;
M>  for (size_t i=1; i<size(); ++i)
M>    if (items[i] >= items[0])
M>      greater_elemets += items[i];
M>    else
M>      smaller_elemets += items[i];

M>  return smaller_elemets.sort() + list(l[0]) + greater_elemets.sort();
M>}
M>


M>Ну а так C++ вариант это все-таки сортировка по месту, да и там элемент по честному вытягивается из середины (чтобы не было падения производительности на почти отсортированных последовательностях). Так что изначально сравнивается оптимизированный код против неоптимального, и задается вопрос: а что понятнее???


Хаскель: «Отсортированый список — это отсортированный список элементов хвоста, меньших головы, затем голова, затем отсортированный список элементов хвоста, не меньших головы».

C++: «Объявим две переменные, пройдем в цикле по элементам, поприсваиваем что-то куда-то».

Если бы я не знал, как вообще отсортировать список (а догадаться не так-то просто), код на Хаскеле привел бы к пониманию и к правильному решению куда быстрее, даже если результат нужно было сформировать на другом языке (да хоть на ассемблере).
До последнего не верил в пирамиду Лебедева.
Re[4]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 13:26
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>C++: «Объявим две переменные, пройдем в цикле по элементам, поприсваиваем что-то куда-то».


RO>Если бы я не знал, как вообще отсортировать список (а догадаться не так-то просто), код на Хаскеле привел бы к пониманию и к правильному решению куда быстрее, даже если результат нужно было сформировать на другом языке (да хоть на ассемблере).


Когда стоит задача просто попрограммироваь, то списки на Хаскеле это очень круто. Но внезапно оказывается, что нужен и перформанс и расход памяти и вообще, ручной контроль ресурсов. Тут то хаскель и дохнет, потмоу студентам все равно придется уметь вручную управлять ресурсами. Это такая задача, что чем больше практики, тм лучше.
Re[5]: TMTOWTDI
От: Roman Odaisky Украина  
Дата: 24.09.12 13:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Когда стоит задача просто попрограммироваь, то списки на Хаскеле это очень круто. Но внезапно оказывается, что нужен и перформанс и расход памяти и вообще, ручной контроль ресурсов. Тут то хаскель и дохнет, потмоу студентам все равно придется уметь вручную управлять ресурсами. Это такая задача, что чем больше практики, тм лучше.


Это, по-видимому, крайний случай premature optimization: когда-нибудь оптимизировать придется, давайте поэтому сразу на C++.

Хаскель и К° очень ценны для понимания концепций и кругозора, даже если конечный продукт написан целиком на чём-нибудь другом.
До последнего не верил в пирамиду Лебедева.
Re[6]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.09.12 14:57
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

I>>Когда стоит задача просто попрограммироваь, то списки на Хаскеле это очень круто. Но внезапно оказывается, что нужен и перформанс и расход памяти и вообще, ручной контроль ресурсов. Тут то хаскель и дохнет, потмоу студентам все равно придется уметь вручную управлять ресурсами. Это такая задача, что чем больше практики, тм лучше.


RO>Это, по-видимому, крайний случай premature optimization: когда-нибудь оптимизировать придется, давайте поэтому сразу на C++.


Ручной контроль ресурсов дело очень тяжкое, потому что бы на выходе из универа был хоть какой то выхлоп, надо начинать учить практически сразу. Си/С++ невозможно поднять за пару месяцев до приемлемого уровня. А ресурсами управлять придется. Концепции и кругозор за семестр другой тоже впихнуть не получится. Потому даётся самое базовое, особенно с учетом особенностей мышления.

RO>Хаскель и К° очень ценны для понимания концепций и кругозора, даже если конечный продукт написан целиком на чём-нибудь другом.


Сначала обучают базовым вещам, а уже потом прививаются абстракции, сиречь концепции, а уже потом — кругозор. Можно и наоборот, но только в ущерб качеству образования.
Все школьные задачи легко и просто решаются с помощью ВМ. Но никто в своем уме не даёт математику начиная с ВМ.
Re[5]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.09.12 17:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>Ага, давай еще формализовывать "эффективность обучения".

G>>Умея работать с функциями и последовательностями можно написать большую часть программ. Зная for и массивы — увы нельзя.

I>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.


А кто говорит пропустить?
Re[8]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.09.12 17:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Когда люди начинают программировать, у них в голове нет никаких абстракций-понятий. Адепты ФП занимаются обманом, не объясняя вычислительную модель заставляют гонять задачи до тех пор, пока в голове у обучаемого не сложится полная картина. Идея рабочая, разница только в том, какой процент студентов сможет освоить это дело.


G>>А зачем знать "вычислительную модель"? Тем более что она сильно зависит от языка.


I>Для того, что бы писать код самостоятельно. Вычислительная модель завит конечно от языка, но неправильно связывать её с языком. Знаешь вычислительную моджель — сможешь решать задачи на её основе. Не знаешь — ищи рецепты в инете.


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

G>>Излишнее внимание к вычислительной модели приводит к тому что на собеседованиях по C# люди говорят что value-type это тип, который размещается на стеке.

I>Твой пример показывает косяки в освоении инструмента. Люди которые вообще не интересуются value-type пишут на редкость тормозной и глючный код.
Ты куда-то в сторону ушел от вопроса. Вопрос заключается в том что люди не понимают разницу между вычислительной моделью и конкретной реализацией в конкретном языке. Это как раз от излишнего внимания к деталям на начальном этапе.
Re[5]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 24.09.12 17:11
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


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


G>>Потому что их учили массвам и циклам for


I>Императивное мышление не получится отменить.


Императивное мышление отлично ложится на обработку последовательностей. Гораздо лучше, чем на цикл for.
Re[4]: TMTOWTDI
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 24.09.12 18:53
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Хаскель: «Отсортированый список — это отсортированный список элементов хвоста, меньших головы, затем голова, затем отсортированный список элементов хвоста, не меньших головы».


С таким пониманием я бы не рискнул программировать. Потому как в случае списка из 10 000 элементов, почти отсортированных (одна транспозиция), мы получим производительность 50M сравнений, и столько же элементов в динамической памяти. Чтобы хоть как-то вразумительно работать, нужно в таком коде постоянно вуидеть C++ аналог. Так что этот хаскельный код читается мною примерно так же, как и C++. Различиетолько в способе записи. Если в C++ это цикл for, то в Haskell это [y | y <- xs, y <= x]. Что тоже цикл, вид сбоку, в котором строится новый список, только чуть другая конструкция. В принципе можно извратится как-то так:

#define DECLARE_SUBLIST(name, var, base, condition)  \
                                                     \  
  list name;                                         \
  {                                                  \
    for(int i=0; i<(base).size(); ++i)               \
    {                                                \
      list_element var = (base)[0];                  \
      if (condition) name += var;                    \
    }                                                \
  }                                                  \



list list::sort() const
{
  if (empty()) return list();
  SPLIT_LIST(*this, head, tile);
  DECLARE_SUBLIST(lesser_elements, y, tail, y < head);
  DECLARE_SUBLIST(greater_elements, y, tail, y >= head);
  return lesser_elements.sort() + head + greater_elemets.sort();
}


только нафига?
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.09.12 06:33
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Потому что их учили массвам и циклам for


I>>Императивное мышление не получится отменить.


G>Императивное мышление отлично ложится на обработку последовательностей. Гораздо лучше, чем на цикл for.


Цикл фор это и есть то самое императивное мышление которое по твоим словам отлично ложится на обработку последовательностей.
Re[9]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.09.12 06:39
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Для того, что бы писать код самостоятельно. Вычислительная модель завит конечно от языка, но неправильно связывать её с языком. Знаешь вычислительную моджель — сможешь решать задачи на её основе. Не знаешь — ищи рецепты в инете.


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


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


I>>Твой пример показывает косяки в освоении инструмента. Люди которые вообще не интересуются value-type пишут на редкость тормозной и глючный код.

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

Твой вопрос был про незнание особенностей конкретной реализации. На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели. По той же самой причине, по которой арифметику осваивают не на формулах, а на палочках, пальцах, фруктах, конфетах и зверятах.
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.09.12 06:40
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Ага, давай еще формализовывать "эффективность обучения".

G>>>Умея работать с функциями и последовательностями можно написать большую часть программ. Зная for и массивы — увы нельзя.

I>>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.


G>А кто говорит пропустить?


Начинать с map вместо императивщины это что по твоему ?
Re[7]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 06:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>>>Потому что их учили массвам и циклам for


I>>>Императивное мышление не получится отменить.


G>>Императивное мышление отлично ложится на обработку последовательностей. Гораздо лучше, чем на цикл for.


I>Цикл фор это и есть то самое императивное мышление которое по твоим словам отлично ложится на обработку последовательностей.


Счегобы? Какое должно быть мышление чтобы родить вложенные циклы типа for?
Ты можешь привести пример рассуждений, которые может провести здоровый человек (не программист), которые могут дать такой результат?
Re[10]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 06:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Для того, что бы писать код самостоятельно. Вычислительная модель завит конечно от языка, но неправильно связывать её с языком. Знаешь вычислительную моджель — сможешь решать задачи на её основе. Не знаешь — ищи рецепты в инете.


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


I>Мозгу для принятия решения в любой ситуации нужна более менее адекватная модель. Проблема заключаетсяв том, что эту модель нельзя загрузить извне.


Причем тут мозг? Мы говорим про программы? Модель принятия решения мозгом бесконечно далека от вычислительных моделей.

I>>>Твой пример показывает косяки в освоении инструмента. Люди которые вообще не интересуются value-type пишут на редкость тормозной и глючный код.

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

I>Твой вопрос был про незнание особенностей конкретной реализации.

Это ты так понял вопрос.

I>На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели.

Счегобы?

I>По той же самой причине, по которой арифметику осваивают не на формулах, а на палочках, пальцах, фруктах, конфетах и зверятах.

Аналогия не прокатила, она вообще из другой оперы.
Re[11]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.09.12 07:02
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Мозгу для принятия решения в любой ситуации нужна более менее адекватная модель. Проблема заключаетсяв том, что эту модель нельзя загрузить извне.


G>Причем тут мозг? Мы говорим про программы? Модель принятия решения мозгом бесконечно далека от вычислительных моделей.


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

I>>Твой вопрос был про незнание особенностей конкретной реализации.

G>Это ты так понял вопрос.

value-type это конкретная реализация, в абстрактной вычислительной модели ничего такого нет и быть не может.

I>>На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели.

G>Счегобы?

Потому что в голове учеников нет ни единой абстракции пригодной для этой деятельности. Абстракции невозможно скопировать в чужую голову.

I>>По той же самой причине, по которой арифметику осваивают не на формулах, а на палочках, пальцах, фруктах, конфетах и зверятах.

G>Аналогия не прокатила, она вообще из другой оперы.

Из той же, поскольку освоение вообще любой деятельности начинается с сенсомоторной стадии, которая по своей природе императивна.
Re[8]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.09.12 07:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Цикл фор это и есть то самое императивное мышление которое по твоим словам отлично ложится на обработку последовательностей.


G>Счегобы? Какое должно быть мышление чтобы родить вложенные циклы типа for?


Императивное, ваш Кэп.

G>Ты можешь привести пример рассуждений, которые может провести здоровый человек (не программист), которые могут дать такой результат?


Я привел все нужные примеры. Покупки в магазине, планирование, реализация планов и тд и тд. Можно глянуть например как мамаши объясняют школьникам начальных классов как чего делать — императивщина чистой воды: "Зайди туда, зайди сюда, если там то, зайти еще туда, спроси вот это, сходу куда скажут, позови вот того и тд и тд и тд"
Re[6]: TMTOWTDI
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 25.09.12 09:18
Оценка:
Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, Mystic, Вы писали:


RO>>>Хаскель: «Отсортированый список — это отсортированный список элементов хвоста, меньших головы, затем голова, затем отсортированный список элементов хвоста, не меньших головы».


RO>Именно. И не наоборот. Только поняв суть алгоритма, можно спускаться с небес на землю и думать, как же его реализовать. По коду на Хаскеле сразу ясна суть и потом уже можно начать выяснять, где узкие места и как это оптимально реализовать. Я вспоминаю, как впервые увидел код quicksort в какой-то книжке по Паскалю — там не было понятно вообще ничего, зато, наверное, работал он быстро.


RO>Мы здесь вроде ведем речь об обучении? Какой подход лучше: отправлять сразу делать всё в императивном стиле, или дать возможность записать алгоритм в человекочитаемом виде, сначала заставляя программу работать пусть медленно, но правильно (ура!), а потом предлагая ученику поразмыслить, как ее ускорить?


Как по мно, суть алгоритма быстрой сортировки в том, чтобы:
(1) найти хитрый трюк, чтобы выполнять ее по месту;
(2) выбирать элемент из середины, а не голову списка.

В противном случае это не быстрая, о очень-очень тормознутая сортировка. Упомянутый исходник на Хаскеле эти основные идеи не иллюстрирует, а значит я не понимаю, на каком основании его можно считать иллюстрацией быстрой сортировки. Это так, хаскель-сортировка
Re[5]: TMTOWTDI
От: Klapaucius  
Дата: 25.09.12 10:03
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Вот такая ссылка есть


Мне, конечно, даже анекдотический опыт интересен. Но тут хватает недостатков. Во-первых, хаскель в данном случае не первый язык вообще, а первый язык, после которого человек решил, что он наконец понял программирование, а до этого не понимал. Такого рода отзывы я и раньше слышал.
Интереснее был бы эксперимент со студентами. Или даже лучше школьниками: студенты соотвествующих специальностей все-таки программировать на чем-то пробовали и до поступления в вуз, а значит эксперимент не чистый получается.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Re[6]: TMTOWTDI
От: Курилка Россия http://kirya.narod.ru/
Дата: 25.09.12 10:13
Оценка:
Здравствуйте, Klapaucius, Вы писали:

K>Здравствуйте, Курилка, Вы писали:


К>>Вот такая ссылка есть


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

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

Ну понятно, что интересней, дал что было, не стреляйте в пианиста...
А про школьников вспомнилось вот это, только там уроки, выводов или чего-нибудь наподобие я не видел.
Re[12]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 21:19
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Мозгу для принятия решения в любой ситуации нужна более менее адекватная модель. Проблема заключаетсяв том, что эту модель нельзя загрузить извне.


G>>Причем тут мозг? Мы говорим про программы? Модель принятия решения мозгом бесконечно далека от вычислительных моделей.


I>Мы говорим про обучение программированию с целью решения современных задач, а не вообще, попрограммировать ради программирования.

Решение современных задач складывается из поиска правильных инструментов и комбинирования их в решение. Причем тут вычислительная модель и устройство инструментов?

I>>>Твой вопрос был про незнание особенностей конкретной реализации.

G>>Это ты так понял вопрос.

I>value-type это конкретная реализация, в абстрактной вычислительной модели ничего такого нет и быть не может.


Что-то я перестаю понимать что ты имеешь ввиду под "абстрактной вычислительной моделью" Может расскажешь?

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

I>>>На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели.

G>>Счегобы?
I>Потому что в голове учеников нет ни единой абстракции пригодной для этой деятельности. Абстракции невозможно скопировать в чужую голову.
Ок, бери бета-редукцию. Примитивнее не придумаешь. Любому знающему арифметику можно объяснить за 2 минуты.
Зачем внимание к деталям конкретных языков?
Re[7]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 21:21
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>>>Ага, давай еще формализовывать "эффективность обучения".

G>>>>Умея работать с функциями и последовательностями можно написать большую часть программ. Зная for и массивы — увы нельзя.

I>>>Это вовсе не значит, что в обучении можно пропустить такой вот этап как императивное программирование.


G>>А кто говорит пропустить?


I>Начинать с map вместо императивщины это что по твоему ?


Где ты нашел слово "пропустить"? Максимум "поменять местами".
Re[7]: TMTOWTDI
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 25.09.12 21:43
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Как по мно, суть алгоритма быстрой сортировки в том, чтобы:

M> (1) найти хитрый трюк, чтобы выполнять ее по месту;
M> (2) выбирать элемент из середины, а не голову списка.

M>В противном случае это не быстрая, о очень-очень тормознутая сортировка. Упомянутый исходник на Хаскеле эти основные идеи не иллюстрирует, а значит я не понимаю, на каком основании его можно считать иллюстрацией быстрой сортировки. Это так, хаскель-сортировка


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

В энергичном варианте быстрая сортировка происходит по принципу "все или ничего", то есть ты не получишь ни один элемент отсортированной последовательности, пока не закончишь считать. В ленивом варианте важно как можно быстрее получить первый элемент списка, так как хвост может быть и не вычислен никогда. Алгоритм на хаскеле адаптирован именно под такой сценарий работы.
Re[8]: TMTOWTDI
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.09.12 07:30
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>В энергичном варианте быстрая сортировка происходит по принципу "все или ничего", то есть ты не получишь ни один элемент отсортированной последовательности, пока не закончишь считать. В ленивом варианте важно как можно быстрее получить первый элемент списка, так как хвост может быть и не вычислен никогда. Алгоритм на хаскеле адаптирован именно под такой сценарий работы.


Я это знаю, но тут как повезет. Например, список отсортирован в обратном порядке. Ну так совпало (например, список отсортирован по размеру з/п в порядке увеличения, а надо отсортировать его в порядке уменьшения + в случае равенства з/п еще какой-то доп. критерий). И что будет в данном случае? Чтобы получить первый элемент, придется таки выполнить O(n^2) сравнений, потому как каждый рекурсивный вызов будет откусывать один наибольший элемент, который нас по твоей агенде не интересует.

Да, на последнем шаге конкатенацию O(n) списков можно и не выполнять, экономия

А хуже всего то, что эти нюансы надо держать постоянно в голове.
Re[9]: TMTOWTDI
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 26.09.12 10:24
Оценка:
Здравствуйте, Mystic, Вы писали:

M>Здравствуйте, gandjustas, Вы писали:


G>>В энергичном варианте быстрая сортировка происходит по принципу "все или ничего", то есть ты не получишь ни один элемент отсортированной последовательности, пока не закончишь считать. В ленивом варианте важно как можно быстрее получить первый элемент списка, так как хвост может быть и не вычислен никогда. Алгоритм на хаскеле адаптирован именно под такой сценарий работы.


M>Я это знаю, но тут как повезет. Например, список отсортирован в обратном порядке. Ну так совпало (например, список отсортирован по размеру з/п в порядке увеличения, а надо отсортировать его в порядке уменьшения + в случае равенства з/п еще какой-то доп. критерий). И что будет в данном случае? Чтобы получить первый элемент, придется таки выполнить O(n^2) сравнений, потому как каждый рекурсивный вызов будет откусывать один наибольший элемент, который нас по твоей агенде не интересует.



M>Да, на последнем шаге конкатенацию O(n) списков можно и не выполнять, экономия



Какова вероятность что список окажется отсортированным в обратном порядке? Это 1/N!, очень маленькое число получится.
Если же распределение входных данных неравномерное, то имеет смысл алгоритмы к этому распределению адаптировать, независимо от того на чем они написаны.
Ну конечно если хочется чтобы все работало быстро.



M>А хуже всего то, что эти нюансы надо держать постоянно в голове.


Вообще-то мы говорим о вопросах обучения, а не оптимизации алгоритмов.
Re[8]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 10:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Начинать с map вместо императивщины это что по твоему ?


G>Где ты нашел слово "пропустить"? Максимум "поменять местами".


Потерять время чтоли ? Ты пойми простую вещь, никто в своем уме не начинает изучать математику с производных и интегралов. Начинают с палочек, косточек, собачек и тд.
В программировании ровно то же — у человека нет никаких абстракций в голове, которые позволят работать с map. Map, то есть проекция, это очень высокоуровневая абстракция. Их невозможно привить человеку каким то хитрым способом.
Re[10]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 10:45
Оценка:
Здравствуйте, samius, Вы писали:

I>>В программировании ровно то же — у человека нет никаких абстракций в голове, которые позволят работать с map. Map, то есть проекция, это очень высокоуровневая абстракция. Их невозможно привить человеку каким то хитрым способом.

S>Эту абстракцию изучают в школе под видом y=f(x)

map относится к организации вычислений, чего в школе не проходят, исключая самые продвинутые школы где учат даже программировать.
Re[11]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.09.12 10:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Эту абстракцию изучают в школе под видом y=f(x)


I>map относится к организации вычислений, чего в школе не проходят, исключая самые продвинутые школы где учат даже программировать.


Что такое организация вычислений? Я это не проходил.
Re[10]: TMTOWTDI
От: Mystic Украина http://mystic2000.newmail.ru
Дата: 26.09.12 11:16
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Какова вероятность что список окажется отсортированным в обратном порядке? Это 1/N!, очень маленькое число получится.

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

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

M>>А хуже всего то, что эти нюансы надо держать постоянно в голове.


G>Вообще-то мы говорим о вопросах обучения, а не оптимизации алгоритмов.


Я не верю в обучение, когда большая часть работы кода магия.
Re[12]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 11:49
Оценка:
Здравствуйте, samius, Вы писали:

I>>map относится к организации вычислений, чего в школе не проходят, исключая самые продвинутые школы где учат даже программировать.


S>Что такое организация вычислений? Я это не проходил.


Программировать не учился ? Так и запишем.
Re[13]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.09.12 11:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>map относится к организации вычислений, чего в школе не проходят, исключая самые продвинутые школы где учат даже программировать.


S>>Что такое организация вычислений? Я это не проходил.


I>Программировать не учился ? Так и запишем.


Запиши лучше что для понимания map организация вычислений не нужна
Re[14]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 12:28
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Что такое организация вычислений? Я это не проходил.


I>>Программировать не учился ? Так и запишем.


S>Запиши лучше что для понимания map организация вычислений не нужна


Нужна. Это хорошо объясняет, почему люди с матбекграудом пишут код который императивнее некуда.
Re[16]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.09.12 14:22
Оценка:
Здравствуйте, samius, Вы писали:

I>>Нужна. Это хорошо объясняет, почему люди с матбекграудом пишут код который императивнее некуда.


S>Это хорошо показывает как ты строишь логические цепочки. Одним бездоказательным утвреждением объясняешь очевидные истины.


Ты путаешь разные по своей природе деятельности — решение задачи, сам процесс вычислений и организацию такого процесса.
Разница простая
1. ты сам решаешь задачу и производишь вычисления
2. ты делаешь так что бы ктото, не обладая вообще никакими знаниями-уменями, смог решить задачу и вычислить результат.

Отсюда ясно, что f(x) это 1, map, т.е.проекция, это 2.

S>Да, есть люди с матбэкграундом, которые пишут императивный код. Есть и другие. А есть и те, которые пишут и императивный и декларативный код. Среди них есть люди с матбэкграундом и без.

S>Вопрос существования таких людей не оспаривается. А для того что бы говорить о тенденциях нужны выборки.

Я видел достаточно много кода который писался именно математиками на разных проектах на разных языках из разных стран в разных областях.
Re[17]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.09.12 16:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Ты путаешь разные по своей природе деятельности — решение задачи, сам процесс вычислений и организацию такого процесса.

I>Разница простая
I>1. ты сам решаешь задачу и производишь вычисления
I>2. ты делаешь так что бы ктото, не обладая вообще никакими знаниями-уменями, смог решить задачу и вычислить результат.

I>Отсюда ясно, что f(x) это 1, map, т.е.проекция, это 2.

Ничего не понял, что и откуда ясно. f(x) — это проекция, map — тоже проекция. Чем тебе f(x) не абстракция для map?
И причем тут "не обладая вообще никакими знаниями-умениями"? И чем в этом аспекте for лучше?

S>>Да, есть люди с матбэкграундом, которые пишут императивный код. Есть и другие. А есть и те, которые пишут и императивный и декларативный код. Среди них есть люди с матбэкграундом и без.

S>>Вопрос существования таких людей не оспаривается. А для того что бы говорить о тенденциях нужны выборки.

I>Я видел достаточно много кода который писался именно математиками на разных проектах на разных языках из разных стран в разных областях.

Много ты видел кода, написанном математиками на хаскеле, например? Или ты судишь по коду на императивных языках?
Re[10]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.09.12 09:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Твой вопрос был про незнание особенностей конкретной реализации. На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели. По той же самой причине, по которой арифметику осваивают не на формулах, а на палочках, пальцах, фруктах, конфетах и зверятах.

Но вот что удивительно — так это то, что в институте за 4 года в людей запихивают примерно 500 страниц справочника Корнов (где весь школьный курс заканчивается на 39й странице), и никаких там палочек, пальцев, фруктов и зверят нету.
Из чего лично я делаю смелый вывод о том, что взрослому мышлению не нужны вспомогательные наглядные примеры для освоения высокоабстрактных концепций. А Y-комбинатор дошкольникам вроде бы никто и не собирался преподавать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 11:13
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Для начинающего естественно использовать именно тот подход, которым он руководствуется в обиходе, например при покупкав магазине или при построении-реализации планов на отпуск и тд и тд и тд.

S>Никто не использует императивное программирование при построении/реализации планов на отпуск.

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

S>А ваши комментарии всего лишь означают, что вы неверно понимаете отличия императивного программирования от декларативного.


Разумеется.
Re[11]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 11:22
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Твой вопрос был про незнание особенностей конкретной реализации. На начальных этапах как раз и нужно это самое внимание к деталям + конкретная реализация вычислительной модели. По той же самой причине, по которой арифметику осваивают не на формулах, а на палочках, пальцах, фруктах, конфетах и зверятах.

S>Но вот что удивительно — так это то, что в институте за 4 года в людей запихивают примерно 500 страниц справочника Корнов (где весь школьный курс заканчивается на 39й странице), и никаких там палочек, пальцев, фруктов и зверят нету.

Справочник Корнов это всего лишь математика и это не является новой деятельностью для студента, т.к. он это математику долбил лет 10 в школе при чем в разных формах и в т.ч. прикладнх, например на уроках физики.
Для того, что бы за пару лет впихнуть эти 500 страниц, надо сначала 10 лет долбить азы в школе. И так везде в образовании — сначала долбишь 5-10 лет конкретные варианты, а потом за год-два-три прокачиваешь общую теорию.

S>Из чего лично я делаю смелый вывод о том, что взрослому мышлению не нужны вспомогательные наглядные примеры для освоения высокоабстрактных концепций. А Y-комбинатор дошкольникам вроде бы никто и не собирался преподавать.


Это неправильный вывод. Программирование — новая область деятельности для студента, при чем принципиально новая. Разница примерно как между программированием и руководством проектом. Потому надо начинать с самых азов а не сразу хвататься за функциональщину на том основании, что она короче и проще.
Фокус в том, что новая деятельность осваивается даже взрослыми начиная с сенсомоторной стадии. Просто потому что в голове нет никаких абстракций пригодных для этой деятельности, их нужно сформировать с нуля, позаимтсвовать не выйдет при всем желании — нету такой фичи, как перепрошить мозг или сдампить базу и поднять на новом сервере.
Re[12]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 27.09.12 11:56
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Справочник Корнов это всего лишь математика и это не является новой деятельностью для студента, т.к. он это математику долбил лет 10 в школе при чем в разных формах и в т.ч. прикладнх, например на уроках физики.

Стесняюсь спросить — а вы его открывали?
I>Для того, что бы за пару лет впихнуть эти 500 страниц, надо сначала 10 лет долбить азы в школе. И так везде в образовании — сначала долбишь 5-10 лет конкретные варианты, а потом за год-два-три прокачиваешь общую теорию.
Там "общего" у разных глав справочника меньше, чем у физкультуры и ботаники.
При преподавании "математики" в ВУЗе используется не арифметика из школы, а более общий навык абстрактного мышления. Этот же навык применяется для всего остального, включая программирование.
I>Это неправильный вывод. Программирование — новая область деятельности для студента, при чем принципиально новая. Разница примерно как между программированием и руководством проектом.

I>Фокус в том, что новая деятельность осваивается даже взрослыми начиная с сенсомоторной стадии. Просто потому что в голове нет никаких абстракций пригодных для этой деятельности, их нужно сформировать с нуля, позаимтсвовать не выйдет при всем желании — нету такой фичи, как перепрошить мозг или сдампить базу и поднять на новом сервере.

"с нуля" не означает "сенсомоторной стадии". Лично в моём университетском курсе всё было безо всякой сенсомоторики. Ввели абстрактное понятие через его определение, начали изучать путём введения и доказательства теорем, проиллюстрировали примерами — всё.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 12:10
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Справочник Корнов это всего лишь математика и это не является новой деятельностью для студента, т.к. он это математику долбил лет 10 в школе при чем в разных формах и в т.ч. прикладнх, например на уроках физики.

S>Стесняюсь спросить — а вы его открывали?

Не стесняйся, спрашивай.

I>>Для того, что бы за пару лет впихнуть эти 500 страниц, надо сначала 10 лет долбить азы в школе. И так везде в образовании — сначала долбишь 5-10 лет конкретные варианты, а потом за год-два-три прокачиваешь общую теорию.

S>Там "общего" у разных глав справочника меньше, чем у физкультуры и ботаники.

Это мягко говоря преувеличение. Все абстракции там завязываются на конкретный сенсомоторный опыт который есть уже у абитуриента. Нет сенсомотрного опыта — нет и абстракций.

S>При преподавании "математики" в ВУЗе используется не арифметика из школы, а более общий навык абстрактного мышления. Этот же навык применяется для всего остального, включая программирование.


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

I>>Это неправильный вывод. Программирование — новая область деятельности для студента, при чем принципиально новая. Разница примерно как между программированием и руководством проектом.


I>>Фокус в том, что новая деятельность осваивается даже взрослыми начиная с сенсомоторной стадии. Просто потому что в голове нет никаких абстракций пригодных для этой деятельности, их нужно сформировать с нуля, позаимтсвовать не выйдет при всем желании — нету такой фичи, как перепрошить мозг или сдампить базу и поднять на новом сервере.

S>"с нуля" не означает "сенсомоторной стадии".

Именно это и означает. А то бы детям сразу можно было y-комбинаторы загружать, бета-редукцию или вовсе высшую математику.

>Лично в моём университетском курсе всё было безо всякой сенсомоторики. Ввели абстрактное понятие через его определение, начали изучать путём введения и доказательства теорем, проиллюстрировали примерами — всё.


Весь университет строится на том, что у тебя уже есть достаточный сенсомоторный опыт. Невозможно "ввести" абстрактное понятие, если ты его не пробовал руками хоть в какой то форме, хотя бы опосредовано.
Re[6]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 13:02
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Дело не в речи, а в способе описания алгоритмов.

S>На всякий случай напомню, что всё отличие императива — в наличии изменяемого состояния.
S>Характерным свидетельством декларативности повседневной деятельности является отсутствие циклов.

Императивное мышление — логическое мышление, предикативное по природе, направленое на то, что нужно сделать, что выполнить, в какую сторону направить действие и тд и тд.

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

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

Можешь глянуть анпример здесь — www.minro.ru/docs/Statya_Nikiforovoy_N.V..doc

Пример абстрактного мышления — "пиво-водка в холодильнике"
Re[7]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 13:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Пример абстрактного мышления — "пиво-водка в холодильнике"


Плохой пример, это тоже императивное, т.к. [находятся]
Re[20]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 13:37
Оценка:
Здравствуйте, samius, Вы писали:

I>>И то и другое проекция, но в одном случае это просто закон, а в другом это не только законо, но и вход, выход и тд и тд. То есть сюда уже вложено понятие списков, типов, особенностей реализации + специфика конкретной вычислительной модели, то есть, всего что необходимо и достаточно для организации вычислений.

S>Т.е. для того что бы решить задачу без map for-ом, нам не нужны теперь ни типы, ни списки/массивы?

Нужны. for это "что сделать". map описывает результат.

>А что такое организация вычислений?


Да все то же — процессор не знает ни математики, ни алгоритмов. Твоя задача сделать так что бы получить нужный результат несмотря на эти недостатки.

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

S>Одного for-а тоже не достаточно для обучения программированию.

Это очевидно. Но факт в том, что императивное мышление прокачано у всех, декларативное — только у некоторых, А программировть учить нужно и тех и других.

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

S>С какими такими инструкциями сталкивается покупатель холодильника или кофемашины что он сразу лучше понимает for?

С любыми вообще говоря. Инструкции это еще один из примеров, не лучше и не хуже чем те что я приводил. Я дал ссылку где то здесь же рядом, для Синклера, можешь посмотреть там про императивное мышление.
Дальше я извини скипнул ен читая, есть причины.
Re[22]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 14:20
Оценка:
Здравствуйте, samius, Вы писали:

I>>Нужны. for это "что сделать". map описывает результат.

S>Раз нужны, значит for в этом отношении не лучше.

Лучше потому что хорошо соотносится с императивным мылением.

I>>Да все то же — процессор не знает ни математики, ни алгоритмов. Твоя задача сделать так что бы получить нужный результат несмотря на эти недостатки.

S>Как пользователю высокоуровневого языка мне нет дела до процессора и организации вычислений. Есть язык, у него есть семантика. Этого достаточно в большинстве случаев. Во всяком случае, с for-ом то же самое. Детям рассказывается его семантика, а не организация его выполнения процессором.

Это справедливо только для того случая когда ты освоил этот высокоуровневый язык.

I>>Это очевидно. Но факт в том, что императивное мышление прокачано у всех, декларативное — только у некоторых, А программировть учить нужно и тех и других.

S>Я не вижу связи между императивным мышлением и императивным кодом.

Императивный код это последовательность действий — что [с]делать. Императивное мышление вобщем тоже "что делать", только модальности разные.

I>>С любыми вообще говоря. Инструкции это еще один из примеров, не лучше и не хуже чем те что я приводил. Я дал ссылку где то здесь же рядом, для Синклера, можешь посмотреть там про императивное мышление.

S>Да, я слежу. Но связь между императивным мышлением и кодом не очевидна по этой ссылке.

Разумеется, ссылка то про интуицию Программирование требует логического мышления. Одно уже прокачано, а второе надо прокачивать. Вопрос — каком способом будет пользоваться новичок ?
Re[5]: Императивное программирование
От: igna Россия  
Дата: 27.09.12 14:45
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Императивное мышление не получится отменить.


В том смысле, что мышление необученного программированию человека является императивным? Не согласен, математику учат раньше, а она ближе к декларативному, а не к императивному программированию.
Re[6]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.09.12 14:54
Оценка:
Здравствуйте, igna, Вы писали:

I>>Императивное мышление не получится отменить.


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


Смотря в каких задачах. Если в типичных — то там императивного не будет. Только как правило все до единой задачи в программировании являются новыми. Не посчитать уравнение, а научить компьютер как считать. Хочешь верь, хочешь нет — но это новая задача для школьника. Для неё нет готовых абстракций, потому в ход идёт самое прокачаное мышление — императивное. Если и оно не помогает — есть еще более примитивное — танцы с бубном.
Re[5]: Императивное программирование
От: igna Россия  
Дата: 27.09.12 14:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Выйди на базар какой или просто послушай, как люди планируют скажем покупки или ремонт и тд и тд — императивщина чистой воды. Обычно это так: "Зайди в Соседи, купи молока, сыра, если не будет Рокфора, возьми Мацарелу, посмотри колбаски, если будут Охотничьи, возьми два десятка, прихвати два десятка яиц и если будет Очаково Черное, возьми две бутылки"


Ты передергиваешь, на самом деле это просто список покупок:

— молоко
— сыр (Рокфор или Моцарелла)
— колбаски Охотничьи, два десятка
— яйца, два десятка
— Очаково Черное, две бутылки
Re[2]: Императивное программирование
От: ӍїϛϮϠǷiя-ȺҜ Россия  
Дата: 27.09.12 19:12
Оценка:
Здравствуйте, DarkGray, Вы писали:


I>>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.


DG>начинай сразу с объяснения машины тьюринга — там концепций еще меньше..


для любой машины Тьюринга может понадобиться "руководство к эксплуатации" Гёделя
Re[8]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.12 02:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Плохой пример, это тоже императивное, т.к. [находятся]

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

Надеюсь, я вам не слишком сильно порвал шаблон.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: TMTOWTDI
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.09.12 07:02
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


I>>Плохой пример, это тоже императивное, т.к. [находятся]

S>Отвратительный пример. В той терминологии, которой вы пытаетесь пользоваться, это системное мышление — то, где человек замечает закономерности в окружающем мире. Благодаря системному мышлению, человек может, будучи в гостях, верно решить задачу "принеси мне пива, и себе одну возьми", поставленную хозяином, сидящим за плейстейшном. Потому что человек не мыслит в терминах императивного алгоритма "обход лабиринта". Он мыслит в терминах универсальных закономерностей типа "пиво — в холодильнике, холодильник — на кухне".

Мысли — да, согласен. Но все-таки изменение состояния человека имеет место быть. А навык изменения этого состояния в сторону усугубления прокачан в большинстве случаев безукоризненно. Разве что к навыку использования for-а сей факт отношения не имеет. Даже если усугублять циклически.
Re[8]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 08:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Императивное мышление — логическое мышление, предикативное по природе, направленое на то, что нужно сделать, что выполнить, в какую сторону направить действие и тд и тд.

S>Кто-то из нас смешивает термины "императивное программирование" и "императивное мышление".
S>Ничего, что они из разных наук? Вас это не смущает?

Я это учитываю.

I>>Пример этого императивного мышления "поищи акции на пиво, если есть бери ведро, если нет — бери томантный сок и водку" — это вполне реальнгый пример. В таком вот духе большинство и рассуждает.

S>Никто так не рассуждает. Жена вообще его отправила за хлебом и сметаной, и никакой водки с пивом она ему не программировала.

Да ладно, сходи на базар какой да посмотри. Многие люди буквально проговаривают свои действия сами с собой или со спутником — императивщина чистой воды.

S>Тем не менее, между приведённым рассуждением и императивной программой — пропасть.


Разумеется, программа это не мышление.

S>Математически это рассуждение вполне себе декларативно. Вы что же думаете, в ФП нет функции выбора? Конечно же есть.


Здесь указывается что делать, что сделать. Всё, приехали, это императивное рассуждение. В ФП никто в своем уме не записывает логику в виде "что делать", "что сделать".

S>Сознание "среднего" человека гораздо больше похоже на эрланг. Незначительная его часть занята "потоком управления" в императивном стиле, который отвечает за выполнение текущей задачи (например, "надо доехать до работы"). Основные действия управляются данными, поступающими на вход, и имеют крайне короткий контекст. Я же вам не зря привёл пример про акцию с пивом. Вся "программа", которая управляет человеком — это предикат вроде "пиво по 35 рублей — это выгодная сделка".


Предикат. А какое мышление предикативно ? Императивное.

>Он сидит себе где-то в сознании, вместе с соображениями типа "вобла — вкусно" и "мужик сказал — мужик сделал". Нет никакого императивного алгоритма типа "проверить все товары на предмет их стоимости". Есть схема стимул — реакция. Увидел пиво — взял пиво. Всё, "программа" отработала.


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

S>Даже если вы откажетесь от общего случая, и попробуете описать крайне целеустремлённого человека, который пришёл за конкретным списком покупок, то вы встрянете в момент выбора заменителей. Внезапно окажется, что наиболее близкая модель к тому, как человек принимает покупательское решение — функциональная.


Наиболее эффективная — функциональная. Но кто тебе сказал что у всех людей в магазине будет прокачано именно такое мышление ?
Откуда дровишки ?

I>>""о! у них акция на разливное пиво — возьму-ка я трёшечку"" — это тоже императивное, т.к. направлено на то, что нужно сделать.


I>>Императивное мышление оно по природе предикативно, то есть, выражет состояние. "возьму-ка я трёшечку" — предикативно. Есть акция на разливное пиво — предикативно Потому весь твой пример вобщем про императивное мышление. Вот "полная трёшечка" — это не будет предикативным, как ни странно.

S>Простите, но вы пишете чушь. Предикативность мышления — это идентификация объектов на основе их признаков.

Нет, это ты пишешь чушь. Если статья слишком сложна для тебя, то берём википедию

В ряду синтаксических конструкций «летящая птица», «полет птицы» и «птица летит» (объединенных содержательным инвариантом, то есть имеющих общий объект обозначения) — последний вариант обозначения общего объекта обладает особым функциональным качеством — предикативностью, то есть выражением состояния объекта. Слово «дождь», произнесенное с особой интонацией, в отличие от нейтральной лексической единицы «дождь» также характеризуется тем, что актуализирует информацию — «[Идет] дождь!». Следовательно, конструкции «птица летит», «Дождь!» являются полными предложениями, осуществляющими законченное сообщение о состоянии объекта/субъекта.


S>Вы же пользуетесь умнообразными словами, совершенно не понимая их смысла.


До свидания,
Re[9]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 08:39
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Плохой пример, это тоже императивное, т.к. [находятся]

S>Отвратительный пример. В той терминологии, которой вы пытаетесь пользоваться, это системное мышление — то, где человек замечает закономерности в окружающем мире. Благодаря системному мышлению, человек может, будучи в гостях, верно решить задачу "принеси мне пива, и себе одну возьми", поставленную хозяином, сидящим за плейстейшном. Потому что человек не мыслит в терминах императивного алгоритма "обход лабиринта". Он мыслит в терминах универсальных закономерностей типа "пиво — в холодильнике, холодильник — на кухне".

ты не показал никакого системного мышления, все твои примеры ничто иное как императивное

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

Ничем иным, как свернутой формой человеческого опыта, и являются пословицы, поговорки, фразеологизмы и другие формы выражения «императивно-

го мышления». Собственно оно и получило название «императивного» поскольку всегда предписывает нам совершать или не совершать определенное действие, указывает, советует как поступить в той или иной ситуации, иначе говоря, выступает, по образному выражению В.Н.Телия [544], как некий императив. [544]

Сравним, например, пословицы разных стран характеризующие многообразие и сложность «образа мира»: «Мир, что огород: в нем все растет» (русская). "У каждого цветка свой аромат» (армянская). «В бутоне роза слаще» (английская). «Один цветок лета не делает» (ногайская). «Не всякий цветок дает плод» (венгерская). «У каждого дерева своя тень» (кубинская).

Re[24]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 08:54
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Раз нужны, значит for в этом отношении не лучше.


I>>Лучше потому что хорошо соотносится с императивным мылением.

S>Чем же map хуже for-а соотносится?

Уровень абстракции НАМНОГО выше. Абстракции нужно прокачивать, а не спускать сверху. Буде возможность спускать абстракции сверху, весь минимум средней школы, университета и послеуниверситетского образования сводился бы к умению читать и писать.

I>>Это справедливо только для того случая когда ты освоил этот высокоуровневый язык.

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

Правильно. Освоил, это значит, что определенные действия, рассуждения автоматизировались считай до рефлексов.
Пропустить этап освоения ? Извини, до токого просветления я еще не подымался.

I>>Императивный код это последовательность действий — что [с]делать. Императивное мышление вобщем тоже "что делать", только модальности разные.

S>

S>Императи́вное программи́рование — это парадигма программирования, которая, в отличие от декларативного программирования, описывает процесс вычисления в виде инструкций, изменяющих состояние программы.


Сначала — что делать, что сделать. А вот будет ли это изменением состояния программы — дело десятое.

S>Соответственно императивный код — это код, описывающий инструкции, изменяющие состояние программы.


out port, value

Где тут изменение состояния программы ? Просто пример корявости википедии.

S>Посмотри на функциональный факториал или квиксорт, там тоже увидишь последовательность действий "что сделать". Ну типа, взять элементы списка меньше первого, вызвать для них рекурсивно qsort...


Это ты сам так хочешь представить программу. Что сделать в ФЯ появляется только в момент ввода-вывода и нигде больше. До этого ты просто описываешь законы.

S>Отличается от императивного лишь наличием инструкций, изменяющих состояние программы.

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

Не аналогии, а причины.

I>>Разумеется, ссылка то про интуицию Программирование требует логического мышления. Одно уже прокачано, а второе надо прокачивать. Вопрос — каком способом будет пользоваться новичок ?

S>Что прокачано? Манипулирование изменением состояния программы? Боюсь, что это новый скилл для начинающего программиста.

Прокачано свойство умышленно передёргивать.
Re[7]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 09:17
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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


I>Смотря в каких задачах. Если в типичных — то там императивного не будет. Только как правило все до единой задачи в программировании являются новыми. Не посчитать уравнение, а научить компьютер как считать. Хочешь верь, хочешь нет — но это новая задача для школьника. Для неё нет готовых абстракций, потому в ход идёт самое прокачаное мышление — императивное. Если и оно не помогает — есть еще более примитивное — танцы с бубном.


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

Итого:
1 Мышление воплощается в словах
2 Внутренняя речь императивна
3 При затруднениях люди проговаривают в уме или даже явно планы и действия по осуществлению выхода из затруднения — внутренняя речь, т.е. не направленая ни на кого.
4 Императивное программивание это примерно так — у человека возникает затруднение когда перед ним ставят задачу, он разрешает эту задачу записывая в определенной нотации свою внутреннюю речь.

Отсюда ясно, почему так много императивных программистов
Re[10]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.09.12 10:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Сравним, например, пословицы разных стран характеризующие многообразие и сложность «образа мира»: «Мир, что огород: в нем все растет» (русская). "У каждого цветка свой аромат» (армянская). «В бутоне роза слаще» (английская). «Один цветок лета не делает» (ногайская). «Не всякий цветок дает плод» (венгерская). «У каждого дерева своя тень» (кубинская).

I>[/q]
Да-да-да, прекрасные цитаты. Они показывают ровно то, за что мы не любим психологов и прочих гуманитариев. Попробуйте расшифровать, как советует нам поступить в той или иной ситуации пословица "не всякий цветок даёт плод".
Увы, оказывается, что никакого императива в этих пословицах нет, ни в бытовом, ни в математическом смысле.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 11:17
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Да-да-да, прекрасные цитаты. Они показывают ровно то, за что мы не любим психологов и прочих гуманитариев.


Это конкретно ты их не любишь.

>Попробуйте расшифровать, как советует нам поступить в той или иной ситуации пословица "не всякий цветок даёт плод".


А что, модальности уже отменили ? Не знал.
"не всякий цветок даёт плод" -> "не стоит ждать плода от каждого цветка"

S>Увы, оказывается, что никакого императива в этих пословицах нет, ни в бытовом, ни в математическом смысле.


Это заблуждение. Если ты внимательно читал ссылки, то там вобщем легко понять что твоя фраза императивна до безобразия
"собака лает", "машина едет", "корован грабят" — императивны. Чем от этого отличается "цветок даёт плод" ?
Re[26]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.09.12 12:34
Оценка:
Здравствуйте, samius, Вы писали:

I>>Уровень абстракции НАМНОГО выше. Абстракции нужно прокачивать, а не спускать сверху. Буде возможность спускать абстракции сверху, весь минимум средней школы, университета и послеуниверситетского образования сводился бы к умению читать и писать.

S>Уровень абстракции средней школы. Вот когда детки уже знают арифметику, представляют что такое функция (не обязательно), когда умеют рисовать зверят на координатной плоскости по набору координат — вот этого уровня уже достаточно для map.

Проверял или голословно ? Я — проверял.

I>>Правильно. Освоил, это значит, что определенные действия, рассуждения автоматизировались считай до рефлексов.

I>>Пропустить этап освоения ? Извини, до токого просветления я еще не подымался.
S>Что? Семантику без процессора освоить не можешь? Извиняю. Пожалеть?

Ручная организация вычислений необходима для освоения. Собственно это и есть освоение. Ты хочешь обойтись без этого. Эдакий способ выучить английский язык без изучения. Дерзай, я так не умею.

I>>Сначала — что делать, что сделать. А вот будет ли это изменением состояния программы — дело десятое.

S>Тебе десятое, а определение это требует.

Википедия может много чего требовать.

I>>Где тут изменение состояния программы ? Просто пример корявости википедии.

S>Да, википедия не совершенна. Инструкции по порче мира туда же. Что бы ты состояние в файл не прятал.

"порча мира" "птица летит" == "портит мир" , так понятно ? Прикинь, каждый момент времени мир не такой, как раньше, потому что птица его портит

I>>Это ты сам так хочешь представить программу. Что сделать в ФЯ появляется только в момент ввода-вывода и нигде больше. До этого ты просто описываешь законы.

S>Так последовательность действий определена законом? Что фильтровать надо перед тем как рекурсивный qsort вызывать, а не после? Можно вообще все тело определение qsort считать отдельной инструкцией-законом по выполнению сортировки.

Я же уже сказал — нужен ввод вывод. Без него программа будет просто описанием какой нибудь хрени.

S>Так что "что делать (сортировать)" написано и в императивном и в функциональном коде. А отличаются они наличием изменяемого состояния.


Оно есть и там и там

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

S>
S>var a = 5;
S>a += 10;
S>

S>к коду
S>
S>var a = 5 + 10;
S>


Это вопрос выбора вычислительной модели а не разницы в строчках.

S>А еще у законов нет вычислительной сложности.


Правильно. А у map — есть.

I>>Не аналогии, а причины.

S>Какие причины?

Те самые о которых я говорю. Не хочешь читать — не пиши ничего в ответ.

I>>Прокачано свойство умышленно передёргивать.

S>Дык, накачаешься тут.
S>Новичек будет пользоваться тем способом, который не потребует прокачки чего-то лишнего и непонятного. В map ему все доступно с 5-го класса (примерно).

Чушь. Как только дело дойдет до ввода-вывода все его познания резко закончатся.

>Может саму реализацию map-а он не напишет, но по делу применить сможет наверняка раньше чем for.


Ты не рассуждай а проверь. Найди ученика который не умеет программировать и подними примерно до уровня, что бы он был в состоянии делать коммиты в продакшн. Я например такой путь проделал неоднократно а потому утверждаю, что твой подход — ахинея.
Re[27]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 29.09.12 10:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Уровень абстракции средней школы. Вот когда детки уже знают арифметику, представляют что такое функция (не обязательно), когда умеют рисовать зверят на координатной плоскости по набору координат — вот этого уровня уже достаточно для map.


I>Проверял или голословно ? Я — проверял.

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

I>Ручная организация вычислений необходима для освоения. Собственно это и есть освоение. Ты хочешь обойтись без этого. Эдакий способ выучить английский язык без изучения. Дерзай, я так не умею.

Не постесняюсь спросить, когда ты изучал логарифм, ты организовывал его вычисления вручную, или так и не освоил?

S>>Тебе десятое, а определение это требует.


I>Википедия может много чего требовать.

Мне вообще непонятно, почему ты знания по теме программирования черпаешь в психологии, там что, ближе чем в википедии? А чо не в медицининском справочнике?

S>>Да, википедия не совершенна. Инструкции по порче мира туда же. Что бы ты состояние в файл не прятал.


I>"порча мира" "птица летит" == "портит мир" , так понятно ? Прикинь, каждый момент времени мир не такой, как раньше, потому что птица его портит

Я понял, что ты написал, но не понял, к чему.

S>>Так последовательность действий определена законом? Что фильтровать надо перед тем как рекурсивный qsort вызывать, а не после? Можно вообще все тело определение qsort считать отдельной инструкцией-законом по выполнению сортировки.


I>Я же уже сказал — нужен ввод вывод. Без него программа будет просто описанием какой нибудь хрени.

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

S>>Так что "что делать (сортировать)" написано и в императивном и в функциональном коде. А отличаются они наличием изменяемого состояния.


I>Оно есть и там и там

Покажи мне его в функциональном qsort-е.

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

S>>
S>>var a = 5;
S>>a += 10;
S>>

S>>к коду
S>>
S>>var a = 5 + 10;
S>>


I>Это вопрос выбора вычислительной модели а не разницы в строчках.

В C# можно выбирать вычислительную модель? Что-то я не помню такого в опциях...

S>>А еще у законов нет вычислительной сложности.


I>Правильно. А у map — есть.

Означает ли это что map не закон?

S>>Какие причины?


I>Те самые о которых я говорю. Не хочешь читать — не пиши ничего в ответ.

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

S>>Новичек будет пользоваться тем способом, который не потребует прокачки чего-то лишнего и непонятного. В map ему все доступно с 5-го класса (примерно).


I>Чушь. Как только дело дойдет до ввода-вывода все его познания резко закончатся.

А в чем проблема?
Или ты думаешь что познаний новичка (который еще не знает map и for) резко достаточно для понимания (ручной) организации строк, вычисления cin/cout или списков аргументов в printf?

>>Может саму реализацию map-а он не напишет, но по делу применить сможет наверняка раньше чем for.


I>Ты не рассуждай а проверь. Найди ученика который не умеет программировать и подними примерно до уровня, что бы он был в состоянии делать коммиты в продакшн. Я например такой путь проделал неоднократно а потому утверждаю, что твой подход — ахинея.

Не умеет программировать — это очень скользкая формулировка, применимая к любому от беспозвоночного до Кента Бека (он сам к себе применял, если чо).
Когда я работал во ВНИИ, была у меня группа новичков. И продакшн пилили. Хоть и были поводы для недовольства, никакой непроходимости с понятием "проекция" они не испытывали.
А вот такие ученики, что не знают for, мне не попадались. И посторонних людей с улицы до продакшна не доводил.

Но речь не обо мне. Расскажи лучше, каких конкретно абстракций не хватает твоим ученикам для понимания map? И как они без этих абстракций пилят в продакшн в конце концов?
Re[28]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 10:05
Оценка:
Здравствуйте, samius, Вы писали:

I>>Проверял или голословно ? Я — проверял.

S>Что ты проверял? Наличие у детей абстракции, позволяющей понять применение функции к последовательности элементов? Ты проверял на тех, кто график функции по точкам не может нарисовать? Где ты их берешь таких особо одаренных?

Твои домыслы я не комментирую.

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


А ты в курсе, в каком классе начинают "рисовать зверят на координатной плоскости по набору координат" ?

I>>Ручная организация вычислений необходима для освоения. Собственно это и есть освоение. Ты хочешь обойтись без этого. Эдакий способ выучить английский язык без изучения. Дерзай, я так не умею.

S>Не постесняюсь спросить, когда ты изучал логарифм, ты организовывал его вычисления вручную, или так и не освоил?

Вычисления не организовывал и это не мешало считать логарифм.

S>>>Тебе десятое, а определение это требует.


I>>Википедия может много чего требовать.

S>Мне вообще непонятно, почему ты знания по теме программирования черпаешь в психологии, там что, ближе чем в википедии? А чо не в медицининском справочнике?

Знания по преподаванию черпаются в педагогике, психологии и много где еще. Странно, да ? Представь себе, здесь программирование ничем не отличается от физики или химии или русской литературы.

S>>>Да, википедия не совершенна. Инструкции по порче мира туда же. Что бы ты состояние в файл не прятал.


I>>"порча мира" "птица летит" == "портит мир" , так понятно ? Прикинь, каждый момент времени мир не такой, как раньше, потому что птица его портит

S>Я понял, что ты написал, но не понял, к чему.

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

I>>Я же уже сказал — нужен ввод вывод. Без него программа будет просто описанием какой нибудь хрени.

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

Без ввода-вывода функциональная программа это просто текст.

I>>Оно есть и там и там

S>Покажи мне его в функциональном qsort-е.

В функциональной программе состояние мира изменится в момент ввода-вывода согласно той декларации которую ты вкладываешь в программу.

I>>Это вопрос выбора вычислительной модели а не разницы в строчках.

S>В C# можно выбирать вычислительную модель? Что-то я не помню такого в опциях...

Твои домыслы я не коментирую.

I>>Правильно. А у map — есть.

S>Означает ли это что map не закон?

map подразумевает расход ресурсов, т.е. память, время, вычислительную сложность и тд.

I>>Те самые о которых я говорю. Не хочешь читать — не пиши ничего в ответ.

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

см мой ответ igna, а твои домыслы я снова не коментирую.

>>Чушь. Как только дело дойдет до ввода-вывода все его познания резко закончатся.

S>А в чем проблема?

Проблема в том, что здесь и начинается деятельность которой он до этого ни разу не занимался — расход ресурсов, время, вычислительная сложность и тд и тд. Отсюда вдруг вырастают структуры данных, алгоритмы и тд и тд которые ему до этого ни разу не были нужны.

S>Или ты думаешь что познаний новичка (который еще не знает map и for) резко достаточно для понимания (ручной) организации строк, вычисления cin/cout или списков аргументов в printf?


Твои домыслы я обратно не коментирую.

I>>Ты не рассуждай а проверь. Найди ученика который не умеет программировать и подними примерно до уровня, что бы он был в состоянии делать коммиты в продакшн. Я например такой путь проделал неоднократно а потому утверждаю, что твой подход — ахинея.

S>Не умеет программировать — это очень скользкая формулировка, применимая к любому от беспозвоночного до Кента Бека (он сам к себе применял, если чо).

Бывает.

S>Когда я работал во ВНИИ, была у меня группа новичков. И продакшн пилили. Хоть и были поводы для недовольства, никакой непроходимости с понятием "проекция" они не испытывали.


Ты их учил программировать полностью с нуля, то есть до этого они программирование ни в каком виде не пробовали, не знали, не проходили ?

S>А вот такие ученики, что не знают for, мне не попадались. И посторонних людей с улицы до продакшна не доводил.


А мне попадались. Потому что люди вообще не умели программировть до того как пришли ко мне.

S>Но речь не обо мне. Расскажи лучше, каких конкретно абстракций не хватает твоим ученикам для понимания map?


расход ресурсов, время, вычислительная сложность, структуры данных.
Все что они могут это абстрактный f(x) при этом
1. не все, а только процентов 10
2. не сразу, а к окончанию школы

>И как они без этих абстракций пилят в продакшн в конце концов?


Без них они ничего не пилят в продакшн. Это у тебя новички умеют все подряд да без освоения.
Re[15]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 10:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Семантически они отличаются модальностью и ничем больше, и это не страшно.

S>Да? А мне казалось, что одна из них — констатация факта, в которой вообще нет никакого субъекта.

Показалось. Я взял твою пословиц и погуглил:

Собственно оно и получило название «императивного» поскольку всегда предписывает нам совершать или не совершать определенное действие, указывает, советует как поступить в той или иной ситуации, иначе говоря, выступает, по образному выражению В.Н.Телия [544], как некий императив. [544]
Сравним, например, пословицы разных стран характеризующие многообразие и сложность «образа мира»: «Мир, что огород: в нем все растет» (русская). "У каждого цветка свой аромат» (армянская). «В бутоне роза слаще» (английская). «Один цветок лета не делает» (ногайская). «Не всякий цветок дает плод» (венгерская). «У каждого дерева своя тень» (кубинская).


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


I>>"каждый человек — млекопитающее, Sinclair человек, следовательно Sinclair млекопитающее"

I>>Это что, так сложно ?
S>Ну конечно же да. Ведь вы берёте два предикативных утверждения, которые по-вашему императивны.

По моему они ассертивны.

S>Применяете к ним третье, неявное утверждение (которое оставлено за кадром). Получаете четвёртое.


Из ложной посылки можно вывести все что угодно.
Re[16]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 10:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

Вы снова привели ровно ту же цитату, на которую я уже отвечал. Именно из этой работы я взял пословицу для примера.
I>Если тебе не нравится, что это считается императивным, обратись к авторам научных работ.
Я уже высказывал своё мнение о гуманитариях вообще и психологах в частности, которые считают, что пословица "В бутоне роза слаще" всегда предписывает нам совершать или не совершать определённые действия.
Я, конечно же, знаю пословицы, которые реально предписывают нам действия. Например — "куй железо, пока горячо".
Но большинство пословиц никакого императива в себе не содержат, как бы гуманитариям ни хотелось его там усмотреть.
И ваши трюки с "модальностью" идут туда же. Если вам неочевидно, почему такая трактовка декларативных утверждений (коих среди пословиц — большинство) — чушь, то я вам поясню на пальцах: из одного декларативного утверждения можно вывести сколько угодно различных императивных утверждений.
Например, из "сколько волка ни корми — он всё в лес смотрит" можно выводить "не стоит ждать от волка благодарности за еду", а можно — "не стоит кормить волка".
Одной модальности тут недостаточно, налицо существенная семантическая разница.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 11:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>А ты в курсе, в каком классе начинают "рисовать зверят на координатной плоскости по набору координат" ?

S>В моё время это было в _пятом_ классе (т.е. в 11 лет).
S>Именно там вводили понятие "график функции". И к "окончанию школы", которое наступало через шесть лет после этого, выпускники умели в математике уже очень-очень много всего достаточно абстрактного.

Единицы способны научиться программированию в это время. Тебя это не смущает ?
Re[31]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 11:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Единицы способны научиться программированию в это время. Тебя это не смущает ?

Лично в моём классе множество способных программировать волшебно совпало с множеством, освоившим школьный курс математики.
Поэтому не вижу, почему я должен смущаться.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 11:32
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Если тебе не нравится, что это считается императивным, обратись к авторам научных работ.

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

Это просто очень сильно свернутое высказывание. Совет как относиться к розам (в частности).

S>Я, конечно же, знаю пословицы, которые реально предписывают нам действия. Например — "куй железо, пока горячо".

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

Содержат в свернутой форме. Императива нет в той фразе про млекопитающих.

S>И ваши трюки с "модальностью" идут туда же. Если вам неочевидно, почему такая трактовка декларативных утверждений (коих среди пословиц — большинство) — чушь, то я вам поясню на пальцах: из одного декларативного утверждения можно вывести сколько угодно различных императивных утверждений.


Если декларативное это свернутое императивное, то да

S>Например, из "сколько волка ни корми — он всё в лес смотрит" можно выводить "не стоит ждать от волка благодарности за еду", а можно — "не стоит кормить волка".


"не стоит кормить волка" здесь не годится, т.к. подразумевает некоторую цель а в пословице ничего про это нет, а вот "волк не меняет свою натуру" — годится.

S>Одной модальности тут недостаточно, налицо существенная семантическая разница.


Модальность и есть существенная разница.
Re[30]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 12:49
Оценка:
Здравствуйте, samius, Вы писали:

I>>Твои домыслы я не комментирую.

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

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

I>>А ты в курсе, в каком классе начинают "рисовать зверят на координатной плоскости по набору координат" ?

S>Зверят мы рисовали в 4м. Тогда же строили графики несложных функций по точкам. В 7-м строили графики практически по-взрослому с элементами мат-анализа. Не говоря уж о том что в школьном курсе геометрии есть такие понятия, как проекция точек на прямую/плоскость и линий на плоскость. Хрен знает в каком классе.

Вот возьми и научи детей в 4м классе _программировать_. Проекция есть — значит ожидаю на выходе вагон малолетних программистов.

I>>Вычисления не организовывал и это не мешало считать логарифм.

S>Ну вот видишь, организация вычислений не требуется для постижения логарифма.

Это нужно для того, что бы запрограммировать вычисления логарифма а не для того что бы его вычислить.

I>>Знания по преподаванию черпаются в педагогике, психологии и много где еще. Странно, да ? Представь себе, здесь программирование ничем не отличается от физики или химии или русской литературы.

S>Действительно странно. Если бы мне в ВУЗ-е математику и программирование читали психологи и много еще кто, я бы наверное был психологом или еще кем.

Для начала тебя 10 лет в школе учили люди, для которых конкретные предметы это побочный эффект. Педагогика, методоки преподавания, психология и тд и тд — вот это основное для обучения. Скажем, если ты не можешь заинтересовать ребенка, то он пройдет мимо твоего предмета, ну разве чтоего ктото другой заинтересует.
Вот вузе найти хороших преподавателей уже сложно найти, потмоу что люди тратят время в основном не на преподавание а на копание в своей области. Потому например в технических очень низкое качество преподавания, хорошо если 40% дадут хоть какой то выхлоп. И 40% это еще хорошая цифра.
Аспирантура дает кое какой ликбез, но в целом, преподаватели в технических вузах ниже плинтуса именно как преподаватели.

I>>Любое действие изменяет состояние мира. В императивном программировании мы всегда указываем последовательность действий и это автоматически означает что состояние мира будет изменяться.

S>Определению это не интересно. Отличие императивного программирования в том, что оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром.

Рассматривай "действие" как абстракцию для " оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром".

I>>Без ввода-вывода функциональная программа это просто текст.

S>Императивная — тоже.

Императивной это не нужно, т.к. мы описываем последовательность действий. Пишешь императивно a = b + 1 и можешь быть уверенным, безо всякого ввода-вывода в ячейке памяти для a будет значение b + 1 и на это будут затрачены ресурсы. В чистом функциональном (а не полуимперативном), это не так. a = b + 1 в таком языке это просто описание a.

I>>В функциональной программе состояние мира изменится в момент ввода-вывода согласно той декларации которую ты вкладываешь в программу.

S>Покажи изменение состояния программы.

до
1 2 3
после
3 2 1

тебе объяснить, почему это разные состояния ?

I>>Твои домыслы я не коментирую.

S>Тогда проккомментируй, как ты выбираешь вычислительную модель

Во время выбора, например, языка программирования или фичи в ЯП.

I>>map подразумевает расход ресурсов, т.е. память, время, вычислительную сложность и тд.

S>И какой вывод?

Вывод такой — map это абстракция слишком высокого уровня что бы скармиливать её рядовому студенту технического вуза.

I>>см мой ответ igna, а твои домыслы я снова не коментирую.

S>В том ответе всего лишь _твои_ домыслы, которые веской причиной не являются, ибо не связаны логикой.

Вообще говоря там нет домыслов. У меня есть кое какие вопросы и пока что я не нашел объяснения в книгах.

I>>Проблема в том, что здесь и начинается деятельность которой он до этого ни разу не занимался — расход ресурсов, время, вычислительная сложность и тд и тд. Отсюда вдруг вырастают структуры данных, алгоритмы и тд и тд которые ему до этого ни разу не были нужны.

S>Ты так об этом пишешь, будто все это беда лишь функционального map-а, и нисколько не нужно для императивного for-а. К тому же, ты сначала пишешь что проблемы представляет функциональный ввод-вывод и напрочь забываешь об этом в пояснении.

Нужно. Императивное как раз и изучают начиная с ввода-вывода.

S>>>Или ты думаешь что познаний новичка (который еще не знает map и for) резко достаточно для понимания (ручной) организации строк, вычисления cin/cout или списков аргументов в printf?


I>>Твои домыслы я обратно не коментирую.

S>Конечно, ведь твоя теория этого не выдержит.

Извини, скажу честно, я не специалист по "Общая теория домыслов samius".

I>>Ты их учил программировать полностью с нуля, то есть до этого они программирование ни в каком виде не пробовали, не знали, не проходили ?

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

То есть, новичков у тебя не было, но ты уверен, что их можно качественно подготовить, если давать Map вместо императивщины ? Это очень смелое утверждение

S>>>А вот такие ученики, что не знают for, мне не попадались. И посторонних людей с улицы до продакшна не доводил.


I>>А мне попадались. Потому что люди вообще не умели программировть до того как пришли ко мне.

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

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

I>>расход ресурсов, время, вычислительная сложность, структуры данных.

S>Т.е. для for-а им абстракций хватает, а для map- нет?

Скажу страшное — для for тоже не хватает абстракций. Хватает для строки print "Hello, World !" и то некоторым объяснять надо.

I>>Все что они могут это абстрактный f(x) при этом

I>>1. не все, а только процентов 10
I>>2. не сразу, а к окончанию школы
S>Такая статистика, конечно, удручает. Но все равно можно сделать вывод что как минимум программы школы достаточно для того что бы овладеть абстракцией проекции. Не сама же она сваливается на 10% учеников 5 лет спустя после ознакомления с ней в школьной программе?

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

I>>Без них они ничего не пилят в продакшн. Это у тебя новички умеют все подряд да без освоения.

S>Я не говорил что без них. Я говорил что не наблюдал проблем с пониманием проекции. Да и ты не назвал ни одной абстракции, которая бы отличала map от for-а, кроме f(x).

С точки зрения освоения неподготовленым человеком я указал все что нужно.
Re[32]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 14:08
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Единицы способны научиться программированию в это время. Тебя это не смущает ?

S>Лично в моём классе множество способных программировать волшебно совпало с множеством, освоившим школьный курс математики.

Что, в пятом классе ? Ну и дела. По окончании школы, сдача экзамена == освоил, почему то оказывается что программировать могут только "технари". Я знаю целую пачку примеров, когда олимпиадники по математике почему то напрочь отказались программировать, просто наотрез, и пошли в экономические дисциплины, а программировать пошли "хорошисты" вроде меня. Или это не считово ?
Re[18]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 14:10
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Если тебе не нравится, что это считается императивным, обратись к авторам научных работ.

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

I>Это просто очень сильно свернутое высказывание. Совет как относиться к розам (в частности).


"В бутоне роза [пахнет] слаще"

Сразу все становится понятным
Re[31]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 01.10.12 14:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Если ты заметил, то с каждым сообщением я игнорирую все больше и больше твоих сообщений, офрмленных определенным образом. Мне эта твоя манера наскучила.


I>Вот возьми и научи детей в 4м классе _программировать_. Проекция есть — значит ожидаю на выходе вагон малолетних программистов.

Я тоже не в восторге от твоих манер. Я настаивал на том, что абстракцию, лежащую в основе понимания map дают в школе, а вовсе не на том что возьмусь учить 4-классников.

S>>Ну вот видишь, организация вычислений не требуется для постижения логарифма.


I>Это нужно для того, что бы запрограммировать вычисления логарифма а не для того что бы его вычислить.

Для того что бы заюзать map в программе его тоже не нужно программировать.

I>>>Знания по преподаванию черпаются в педагогике, психологии и много где еще. Странно, да ? Представь себе, здесь программирование ничем не отличается от физики или химии или русской литературы.

S>>Действительно странно. Если бы мне в ВУЗ-е математику и программирование читали психологи и много еще кто, я бы наверное был психологом или еще кем.

I>Для начала тебя 10 лет в школе учили люди, для которых конкретные предметы это побочный эффект. Педагогика, методоки преподавания, психология и тд и тд — вот это основное для обучения. Скажем, если ты не можешь заинтересовать ребенка, то он пройдет мимо твоего предмета, ну разве чтоего ктото другой заинтересует.

Это не так. Интерес лишь частный случай мотивации. Для того что бы мотивировать вовсе не обязательно знать методики, психологию, и тд и тд. Достаточно просто быть истеричкой (например). А учился программировать я по инструкции к калькулятору MK-61. Психологией и методиками там и не пахло... Было это за пару лет до уроков информатики в школе, где учили правильным концом вставлять дискету. Так что не надо мне про педагогику и психологию.
I>Вот вузе найти хороших преподавателей уже сложно найти, потмоу что люди тратят время в основном не на преподавание а на копание в своей области. Потому например в технических очень низкое качество преподавания, хорошо если 40% дадут хоть какой то выхлоп. И 40% это еще хорошая цифра.
Учиться техническим наукам у педагогов и психологов — там выхлопа будет еще меньше.
I>Аспирантура дает кое какой ликбез, но в целом, преподаватели в технических вузах ниже плинтуса именно как преподаватели.
К счастью, преподаватели в вузах преподают взрослым людям, а не детсаду. И смотря некоторые лекции из зарубежных вузов, замечу, что такие клоуны как Ерик Мейер, там большая редкость. Никаких там ужимок, психологических примемов. Препод просто заходит в аудиторию, здоровается и включает воспроизведение лекции. При этом он вовсе не пытается привлекать внимание аудитории к своей персоне.

S>>Определению это не интересно. Отличие императивного программирования в том, что оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром.


I>Рассматривай "действие" как абстракцию для " оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром".

Так и есть, действия — они такие. И именно действия отличают императивное программирование, а не наклонение.

I>>>Без ввода-вывода функциональная программа это просто текст.

S>>Императивная — тоже.

I>Императивной это не нужно, т.к. мы описываем последовательность действий. Пишешь императивно a = b + 1 и можешь быть уверенным, безо всякого ввода-вывода в ячейке памяти для a будет значение b + 1 и на это будут затрачены ресурсы. В чистом функциональном (а не полуимперативном), это не так. a = b + 1 в таком языке это просто описание a.

Только зачем нужно это действие без возможности вывода?

S>>Покажи изменение состояния программы.


I>до

I>1 2 3
I>после
I>3 2 1

I>тебе объяснить, почему это разные состояния ?

Лучше объясни, где тут изменение состояния

S>>Тогда проккомментируй, как ты выбираешь вычислительную модель


I>Во время выбора, например, языка программирования или фичи в ЯП.

Вот ты выбрал C#. И что, теперь в нем нельзя писать функционально?

I>>>map подразумевает расход ресурсов, т.е. память, время, вычислительную сложность и тд.

S>>И какой вывод?

I>Вывод такой — map это абстракция слишком высокого уровня что бы скармиливать её рядовому студенту технического вуза.

При решении задачи проектирования массива в массив с помощью for-а внезапно оказывается что нужны те же ресурсы, т.е. память, время, сложность и т.п. Слишком сложно для рядового студента технического вуза. Не находишь?

I>Вообще говоря там нет домыслов. У меня есть кое какие вопросы и пока что я не нашел объяснения в книгах.

Просто интересно, а ответы на вопросы по кораблестроению ты бы тоже в книгах по психологии искал?

S>>Ты так об этом пишешь, будто все это беда лишь функционального map-а, и нисколько не нужно для императивного for-а. К тому же, ты сначала пишешь что проблемы представляет функциональный ввод-вывод и напрочь забываешь об этом в пояснении.


I>Нужно. Императивное как раз и изучают начиная с ввода-вывода.

Да. Давай только уточним, насколько глубоко его там изучают? Новичкам просто говорят что выводить нужно так:
cout << "Hello";
Console.WriteLine("Hello");
printf("Hello");

Много ли новичек знает об устройстве этих способов вывода? Так вот, если не погружаться в детали, то вывод в том же хаскеле не сильно страшнее выглядит. А если погружаться, то уж всяко не страшнее cout.

I>Извини, скажу честно, я не специалист по "Общая теория домыслов samius".

Ты и в своей теории не специалист. Иначе бы домыслы samius не ставили ее в неудобный ракурс.

I>То есть, новичков у тебя не было, но ты уверен, что их можно качественно подготовить, если давать Map вместо императивщины ? Это очень смелое утверждение

Я знаю что есть успешный опыт, правда не мой.

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


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

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

S>>Т.е. для for-а им абстракций хватает, а для map- нет?


I>Скажу страшное — для for тоже не хватает абстракций. Хватает для строки print "Hello, World !" и то некоторым объяснять надо.

Т.е. то что для for-а асбтракций не хватает, тебе не мешает его давать. Теперь я вообще не понимаю, о чем мы спорим.

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



I>С точки зрения освоения неподготовленым человеком я указал все что нужно.

Значит у меня не хватает абстракций что бы принять твои довыды.
Re[32]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 01.10.12 14:58
Оценка:
Здравствуйте, samius, Вы писали:

I>>Вот возьми и научи детей в 4м классе _программировать_. Проекция есть — значит ожидаю на выходе вагон малолетних программистов.

S>Я тоже не в восторге от твоих манер. Я настаивал на том, что абстракцию, лежащую в основе понимания map дают в школе, а вовсе не на том что возьмусь учить 4-классников.

Начинают давать в 4м классе и это ни о чем не говорит.

I>>Это нужно для того, что бы запрограммировать вычисления логарифма а не для того что бы его вычислить.

S>Для того что бы заюзать map в программе его тоже не нужно программировать.

Нужно уметь написать свой собственный map.

S>Это не так. Интерес лишь частный случай мотивации. Для того что бы мотивировать вовсе не обязательно знать методики, психологию, и тд и тд. Достаточно просто быть истеричкой (например).


Истерички сообщают в основном отрицательную мотивацию. Нужна даже не положительная, а самый что ни есть непосредственный интерес.

>А учился программировать я по инструкции к калькулятору MK-61. Психологией и методиками там и не пахло... Было это за пару лет до уроков информатики в школе, где учили правильным концом вставлять дискету. Так что не надо мне про педагогику и психологию.


Интерес у тебя уже был. Следовательно для мотивации учитель не был нужен. С самообразованием есть проблема, примерно как и с самолечением — получается у единиц.

S>Учиться техническим наукам у педагогов и психологов — там выхлопа будет еще меньше.


Зато если технические дисциплины преподает технарь с педагогическим образованием то результаты на голову выше чем у любого другого преподавателя.

I>>Аспирантура дает кое какой ликбез, но в целом, преподаватели в технических вузах ниже плинтуса именно как преподаватели.

S>К счастью, преподаватели в вузах преподают взрослым людям, а не детсаду. И смотря некоторые лекции из зарубежных вузов, замечу, что такие клоуны как Ерик Мейер, там большая редкость. Никаких там ужимок, психологических примемов. Препод просто заходит в аудиторию, здоровается и включает воспроизведение лекции. При этом он вовсе не пытается привлекать внимание аудитории к своей персоне.

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

I>>Рассматривай "действие" как абстракцию для " оно явно манипулирует состоянием, явно описанным в программе, либо явно манипулирует внешним миром".

S>Так и есть, действия — они такие. И именно действия отличают императивное программирование, а не наклонение.

Я и говорю про действия, если ты не заметил.

I>>Императивной это не нужно, т.к. мы описываем последовательность действий. Пишешь императивно a = b + 1 и можешь быть уверенным, безо всякого ввода-вывода в ячейке памяти для a будет значение b + 1 и на это будут затрачены ресурсы. В чистом функциональном (а не полуимперативном), это не так. a = b + 1 в таком языке это просто описание a.

S>Только зачем нужно это действие без возможности вывода?

Незачем.

I>>до

I>>1 2 3
I>>после
I>>3 2 1

I>>тебе объяснить, почему это разные состояния ?

S>Лучше объясни, где тут изменение состояния

Объясняю — в изменении каждой позиции.

I>>Во время выбора, например, языка программирования или фичи в ЯП.

S>Вот ты выбрал C#. И что, теперь в нем нельзя писать функционально?

Функционально — нельзя. В функциональном стиле — можно. Программа вобщем все равно будет императивной.

I>>Вывод такой — map это абстракция слишком высокого уровня что бы скармиливать её рядовому студенту технического вуза.

S>При решении задачи проектирования массива в массив с помощью for-а внезапно оказывается что нужны те же ресурсы, т.е. память, время, сложность и т.п. Слишком сложно для рядового студента технического вуза. Не находишь?

Нахожу. Потому до for студенту надо еще добраться. Многие так и не добираются. Я на таких зарабатывал пиво, шампанское и деньги.

I>>Вообще говоря там нет домыслов. У меня есть кое какие вопросы и пока что я не нашел объяснения в книгах.

S>Просто интересно, а ответы на вопросы по кораблестроению ты бы тоже в книгах по психологии искал?

В книгах по психиатрии

I>>Нужно. Императивное как раз и изучают начиная с ввода-вывода.

S>Да. Давай только уточним, насколько глубоко его там изучают? Новичкам просто говорят что выводить нужно так:
S>
S>cout << "Hello";
S>Console.WriteLine("Hello");
S>printf("Hello");
S>

S>Много ли новичек знает об устройстве этих способов вывода? Так вот, если не погружаться в детали, то вывод в том же хаскеле не сильно страшнее выглядит. А если погружаться, то уж всяко не страшнее cout.

А я где то говорил про cout или конкретный язык ?

I>>Извини, скажу честно, я не специалист по "Общая теория домыслов samius".

S>Ты и в своей теории не специалист. Иначе бы домыслы samius не ставили ее в неудобный ракурс.

Тут примерно как в пословице про собаку и караван.

I>>То есть, новичков у тебя не было, но ты уверен, что их можно качественно подготовить, если давать Map вместо императивщины ? Это очень смелое утверждение

S>Я знаю что есть успешный опыт, правда не мой.

Наверняка единичный. А индустрии нужны миллионы.

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

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

Где ты видишь что я на контингент жалуюсь ?

I>>Скажу страшное — для for тоже не хватает абстракций. Хватает для строки print "Hello, World !" и то некоторым объяснять надо.

S>Т.е. то что для for-а асбтракций не хватает, тебе не мешает его давать. Теперь я вообще не понимаю, о чем мы спорим.

Я удивляюсь, как ты умудряешься читать
Re[33]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 15:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Что, в пятом классе ? Ну и дела.


Зачем? Программировать пошли люди после школы. Я вообще не понимаю, зачем вы рассматриваете вопросы обучения программированию в пятом классе. В жизни такая задача не стоит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 01.10.12 16:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Содержат в свернутой форме. Императива нет в той фразе про млекопитающих.


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

S>>Например, из "сколько волка ни корми — он всё в лес смотрит" можно выводить "не стоит ждать от волка благодарности за еду", а можно — "не стоит кормить волка".


I>"не стоит кормить волка" здесь не годится, т.к. подразумевает некоторую цель а в пословице ничего про это нет, а вот "волк не меняет свою натуру" — годится.

Не, не годится, так как из этого нельзя вывести никакого императива. Один пост назад вас почему-то не смутило отсутствие цели, и вы легким магнием руки аналогичную пословицу подвергли ровно тому же преобразованию.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.12 06:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

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


Где же тут изменение состояния ?

S>>>Например, из "сколько волка ни корми — он всё в лес смотрит" можно выводить "не стоит ждать от волка благодарности за еду", а можно — "не стоит кормить волка".


I>>"не стоит кормить волка" здесь не годится, т.к. подразумевает некоторую цель а в пословице ничего про это нет, а вот "волк не меняет свою натуру" — годится.

S>Не, не годится, так как из этого нельзя вывести никакого императива. Один пост назад вас почему-то не смутило отсутствие цели, и вы легким магнием руки аналогичную пословицу подвергли ровно тому же преобразованию.

А здесь есть изменение состояния — "менять", так что все в порядке.
Re[21]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.12 08:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Где же тут изменение состояния ?

S>А его нигде нет. Вам совершенно не нужно "изменение состояния" для того, чтобы объявить фразу императивной.

Нужно.

S>"Собака лает" — это свойство собаки, а вовсе не изменение состояния. "Пиво по 30 рублей литр — это выгодная сделка" — никакого изменения состояния.


А здесь есть изменение состояния

I>>А здесь есть изменение состояния — "менять", так что все в порядке.

S>Да ничего не в порядке. Вы натягиваете презерватив на глобус и находите общности там, где их нет, и различия там, где их нет.
S>Зачем?

Это ты почему то не хочешь замечать разницу То есть, отказываешься видеть разницу между императивными и ассертивным высказываниями, но видишь её между свернутыми и несвернутыми императивными.

S>Иперативное программирование отличается от, скажем, функционального вовсе не тем, что оно "указывает, что делать". Оно оперирует изменяемым состоянием некоторого вычислителя. SQL, к примеру, тоже "императивен" в том смысле, что у него все стейтменты представляют собой глаголы в повелительном наклонении. Однако это никак не влияет на его декларативную природу.


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

Вобщем если тебе нечего добавить, то можно и не продолжать, а то у тебя всё чаще появляются аргументы в духе "чушь".
Re[19]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 02.10.12 09:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Сразу все становится понятным

Ну естественно. Вы исказили смысл исходного высказывания, при этом никаких действий, как не было — так и нет, зато "всё становится понятным".
Я на этом, пожалуй, закончу плодотворное общение с вами, т.к. вы ухитряетесь писать чушь даже о самых простых и понятных вещах.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.12 09:49
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну естественно. Вы исказили смысл исходного высказывания, при этом никаких действий, как не было — так и нет, зато "всё становится понятным".


Эдак окажется что смысл пословиц нельзя обнаружить в принципе

S>Я на этом, пожалуй, закончу плодотворное общение с вами, т.к. вы ухитряетесь писать чушь даже о самых простых и понятных вещах.


Стоит пройти ликбез прежде чем огульно отрицать все подряд, ибо одной математикой сыт не будешь.
Re[20]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.12 09:52
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Сразу все становится понятным

S>Ну естественно. Вы исказили смысл исходного высказывания, при этом никаких действий, как не было — так и нет, зато "всё становится понятным".

Вопрос, эллипсис тебе знаком или как ? На счет искажения, тут чел завел разговор про шампанское.
Расскажи, как ты понимаешь фразу "Шампанского !" только без искажения смысла — ничего не дополнять, ничего не выкидывать. А то я вот понимаю вот так "[Принесите] шампанского !" — наверняка это искажения смысла с твоей точки зрения, а то ведь слово новое добавляется.
Re[33]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.10.12 11:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Начинают давать в 4м классе и это ни о чем не говорит.

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

S>>Для того что бы заюзать map в программе его тоже не нужно программировать.


I>Нужно уметь написать свой собственный map.

Ну это проще, чем написать свой собственный for.

I>Истерички сообщают в основном отрицательную мотивацию. Нужна даже не положительная, а самый что ни есть непосредственный интерес.

вовсе не нужен.

I>Интерес у тебя уже был. Следовательно для мотивации учитель не был нужен. С самообразованием есть проблема, примерно как и с самолечением — получается у единиц.

Интерес у меня был к программированию. А к математике — не было и нет до сих пор. Давалась она мне лишь потому что математичка была вампиром и уходил я с уроков математики с колами и сединой.

S>>Учиться техническим наукам у педагогов и психологов — там выхлопа будет еще меньше.


I>Зато если технические дисциплины преподает технарь с педагогическим образованием то результаты на голову выше чем у любого другого преподавателя.

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

I>А я что, где то говорил для обучения что надо привлекать внимание к своей персоне ? Нужно правильно строить процесс обучения, вот и все.

Беречь деток от лишних абстракций?

I>Я и говорю про действия, если ты не заметил.

Это я говорю про действия, а ты про наклонения.

S>>Только зачем нужно это действие без возможности вывода?


I>Незачем.

Значит императивное программирование чувствительно к наличию вывода ничуть не меньше. Следующий аргумент...

I>>>до

I>>>1 2 3
I>>>после
I>>>3 2 1

S>>Лучше объясни, где тут изменение состояния


I>Объясняю — в изменении каждой позиции.

Интересно. Отсюда можно проэкстраполировать продолжение твоей теории. Любой язык, где можно отсортировать последовательность (пусть даже тривиальную из 2х элементов), будет явно оперировать состоянием , раз позиции элементов до и после отличаются, даже если сортировка была не по месту, даже если это SQL, а следовательно, императивен.

Развлекся, спасибо.

I>>>Во время выбора, например, языка программирования или фичи в ЯП.

S>>Вот ты выбрал C#. И что, теперь в нем нельзя писать функционально?

I>Функционально — нельзя. В функциональном стиле — можно. Программа вобщем все равно будет императивной.

Пусть будет в функциональном стиле. А по какому соображению программа на C# в функциональном стиле все равно будет императивной?

I>Нахожу. Потому до for студенту надо еще добраться. Многие так и не добираются. Я на таких зарабатывал пиво, шампанское и деньги.

Так это по твоей вине они for не осилили

S>>Просто интересно, а ответы на вопросы по кораблестроению ты бы тоже в книгах по психологии искал?


I>В книгах по психиатрии

Тогда все понятно. Нет, правда, все встало на места.

I>>>Нужно. Императивное как раз и изучают начиная с ввода-вывода.

S>>Да. Давай только уточним, насколько глубоко его там изучают? Новичкам просто говорят что выводить нужно так:
S>>
S>>cout << "Hello";
S>>Console.WriteLine("Hello");
S>>printf("Hello");
S>>

S>>Много ли новичек знает об устройстве этих способов вывода? Так вот, если не погружаться в детали, то вывод в том же хаскеле не сильно страшнее выглядит. А если погружаться, то уж всяко не страшнее cout.

I>А я где то говорил про cout или конкретный язык ?

Дык возьми любой язык общего назначения, который в программе ВУЗ-а изучается, залезь под капот ввода-вывода, найдешь массу интересного.
Вот еще вопрос создрел. Ты настаиваешь на том, что для того что бы юзать map надо уметь его самому написать. А как ты в этом аспекте относишься ко вводу-выводу? Должен ли студент написать его самостоятельно для того что бы уметь его вызывать? До или после for-а твои подопечные пишут ввод-вывод?

I>Тут примерно как в пословице про собаку и караван.

Примерно не так. Караван он тупо идет, а ты то отвечаешь, то нет. Вот я и полагаю, что не отвечаешь там где неудобно.

S>>Я знаю что есть успешный опыт, правда не мой.


I>Наверняка единичный. А индустрии нужны миллионы.

Это мы уже обсуждали и ты был неубедителен.

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


I>Где ты видишь что я на контингент жалуюсь ?

Я думал что ты недоволен отсутствием нужных абстракций у 90% после школы. Показалось. Видимо отсутствие абстракций это твое шампанское и пиво.

I>Я удивляюсь, как ты умудряешься читать

А я — как ты умудряешься писать такое.
Re[34]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.10.12 12:24
Оценка:
Здравствуйте, samius, Вы писали:

I>>Начинают давать в 4м классе и это ни о чем не говорит.

S>Говорит о том что нужная абстракция дана. Те кто ей не владеют, даже график функции построить не смогут.

"Дана" можно сказать когда люди на раз используют её не глядя в учебник при в решении задач. В 4м они делают все руками, а надо дождаться пока все это не начнут делать в уме автоматически, а на это нужно очень много времени.

I>>Нужно уметь написать свой собственный map.

S>Ну это проще, чем написать свой собственный for.

Текста меньше. Проще — вряд ли.

I>>Истерички сообщают в основном отрицательную мотивацию. Нужна даже не положительная, а самый что ни есть непосредственный интерес.

S>вовсе не нужен.

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

Вобщем после этого твоего "вовсе не нужен" сказаное про интерес у меня вообще пропало чего либо писать тебе в ответ.
Re[35]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 02.10.12 16:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Говорит о том что нужная абстракция дана. Те кто ей не владеют, даже график функции построить не смогут.


I>"Дана" можно сказать когда люди на раз используют её не глядя в учебник при в решении задач. В 4м они делают все руками, а надо дождаться пока все это не начнут делать в уме автоматически, а на это нужно очень много времени.

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

I>>>Истерички сообщают в основном отрицательную мотивацию. Нужна даже не положительная, а самый что ни есть непосредственный интерес.

S>>вовсе не нужен.

I>Всего есть три вида мотивации. Положительная, отрицательная и этот самый непосредтсвенный интерес. Судя по твоему высказыванию, ты ратуешь за отрицательную мотивацию (истеричка) или положительную (раз интерес не нужен). Отрицательная — угроза наказания, положительная — учеба за конфетку. Ну, то есть, проповедуюешь в чистом виде метод кнута и пряника !

I>Добро пожаловать в средневековье.
Я не проповедую кнут и пряник. Я лишь утверждаю что интерес не является единственным мотиватором.

I>Вобщем после этого твоего "вовсе не нужен" сказаное про интерес у меня вообще пропало чего либо писать тебе в ответ.

Не рассчитывал узнать в твоем ответе что-либо интересное. Переживу.
Re[9]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.12 18:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Начинать с map вместо императивщины это что по твоему ?


G>>Где ты нашел слово "пропустить"? Максимум "поменять местами".


I>Потерять время чтоли ? Ты пойми простую вещь, никто в своем уме не начинает изучать математику с производных и интегралов. Начинают с палочек, косточек, собачек и тд.

I>В программировании ровно то же — у человека нет никаких абстракций в голове, которые позволят работать с map. Map, то есть проекция, это очень высокоуровневая абстракция. Их невозможно привить человеку каким то хитрым способом.

Да, для map надо рекурсивные функции и рекурсивные структуры данных объяснить. Дело двух занятий. Если же пойти по пути объяснения с битов, байтов и машинных команд, то к map и за два года не придешь.

Чтобы управлять машиной надо знать что есть двигатель и колеса и как они связаны друг с другом. Но внутреннее устройство двигателя знать совершенно необязательно.
Re[14]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 02.10.12 18:15
Оценка:
Здравствуйте, Ikemefula, Вы писали:

G>>Что-то я перестаю понимать что ты имеешь ввиду под "абстрактной вычислительной моделью" Может расскажешь?

I>машина тьюринга — абстрактная модель. В ней нет никаких value-type и тд и тд.
CLR тоже абстрактная модель.

G>>Вот вычислительная модель CLR абстрактна, в том смысле что конкретной реализации нет. Лямбда-исчисление тоже абстрактно. При некоторых ограничениях эти модели дают одинаковый результат. При этом модели сильно разные. Чему ты предлагаешь обучать?


I>Начинать с обычного императивного программирования и формировать нужные абстракции. Дальше можно и лямбда счисление и CLR и все что угодно.

А почему бы не начать с лямбда-исчисления? Ведь начиная с него надо гораздо меньший путь пройти до map\fold, а с ними уже можно написать реальные программы.


G>>Ок, бери бета-редукцию. Примитивнее не придумаешь. Любому знающему арифметику можно объяснить за 2 минуты.

I>Идёт. Мой сын которому скоро 5, как раз осваивает арифметику. Устроим сеанс мастер-класса, ты будешь объяснять ему бета редукцию. Не дай бог он этого не поймёт — пеняй на себя.
Данивопрос.
Re[21]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 07:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Расскажи, как ты понимаешь фразу "Шампанского !" только без искажения смысла — ничего не дополнять, ничего не выкидывать. А то я вот понимаю вот так "[Принесите] шампанского !" — наверняка это искажения смысла с твоей точки зрения, а то ведь слово новое добавляется.
Ну, для начала стоит понять, что без контекста эта фраза может иметь несколько разных смыслов.
Вы уже предположили некоторый контекст, и в нём эта фраза действительно эквивалентнта фразе "Принеси[те] шампанского".
В другом контексте эта фраза может означать "Позовите Шампанского" — сами догадаетесь, в каком, или надо подробно объяснять?
А в общем случае нельзя применять произвольные трансформации к фразам, и считать семантику сохранившейся.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
й
Re[22]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 08:14
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:

I>>Расскажи, как ты понимаешь фразу "Шампанского !" только без искажения смысла — ничего не дополнять, ничего не выкидывать. А то я вот понимаю вот так "[Принесите] шампанского !" — наверняка это искажения смысла с твоей точки зрения, а то ведь слово новое добавляется.
S>Ну, для начала стоит понять, что без контекста эта фраза может иметь несколько разных смыслов.
S>Вы уже предположили некоторый контекст, и в нём эта фраза действительно эквивалентнта фразе "Принеси[те] шампанского".
S>В другом контексте эта фраза может означать "Позовите Шампанского" — сами догадаетесь, в каком, или надо подробно объяснять?
S>А в общем случае нельзя применять произвольные трансформации к фразам, и считать семантику сохранившейся.

Контекст никуда не девается. Отсюда не ясно, где ты увидел произвольные трансформации, т.к. я показывал ровно тож самое что и в случае с шампанским.
Re[10]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 08:32
Оценка:
Здравствуйте, gandjustas, Вы писали:

>Да, для map надо рекурсивные функции и рекурсивные структуры данных объяснить. Дело двух занятий. Если же пойти по пути объяснения с битов, байтов и машинных команд, то к map и за два года не придешь.


Не смеши людей

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


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

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

В программировании ничего подобного нет и быть не может, это осваивается буквально с нуля, т.к. математика сама по себе "не работает".
Re[36]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 08:39
Оценка:
Здравствуйте, samius, Вы писали:

I>>"Дана" можно сказать когда люди на раз используют её не глядя в учебник при в решении задач. В 4м они делают все руками, а надо дождаться пока все это не начнут делать в уме автоматически, а на это нужно очень много времени.

S>Я даже не пойму, куда там в учебник смотреть при проецировании. Разве что в залезть в википедию, подивиться на определение бетта-редукции, но мне кажется что 99% школьников могут обойтись без этого.

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

I>>Всего есть три вида мотивации. Положительная, отрицательная и этот самый непосредтсвенный интерес. Судя по твоему высказыванию, ты ратуешь за отрицательную мотивацию (истеричка) или положительную (раз интерес не нужен). Отрицательная — угроза наказания, положительная — учеба за конфетку. Ну, то есть, проповедуюешь в чистом виде метод кнута и пряника !

I>>Добро пожаловать в средневековье.
S>Я не проповедую кнут и пряник. Я лишь утверждаю что интерес не является единственным мотиватором.

"вовсе не нужен" Интерес это единсвтенный непосредственный мотиватор, и он дает наилучшие результаты при обучении, настолько лучшие, что по сравнению с ним отрицательной и положительной мотивацией можно пренебречь.
Но раз у тебя сложности с русским языком ("вовсе не нужен"), то тем нет смысла продолжать. Но по крайней мере ясно, откуда корни твоих передёргиваний, буду знать на будущее.
Re[15]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 08:45
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>Что-то я перестаю понимать что ты имеешь ввиду под "абстрактной вычислительной моделью" Может расскажешь?

I>>машина тьюринга — абстрактная модель. В ней нет никаких value-type и тд и тд.
G>CLR тоже абстрактная модель.

CLR относительно машины тьюринга вполне конкретная.

G>>>Вот вычислительная модель CLR абстрактна, в том смысле что конкретной реализации нет. Лямбда-исчисление тоже абстрактно. При некоторых ограничениях эти модели дают одинаковый результат. При этом модели сильно разные. Чему ты предлагаешь обучать?


I>>Начинать с обычного императивного программирования и формировать нужные абстракции. Дальше можно и лямбда счисление и CLR и все что угодно.

G>А почему бы не начать с лямбда-исчисления? Ведь начиная с него надо гораздо меньший путь пройти до map\fold, а с ними уже можно написать реальные программы.

Потому что лямбда-счисление это очень высокоуровневая абстракция. Пойми простую вещь — математику осваивают с палочек. Например зная ВМ весь школьный курс можно уложить примерно в страничку текста. Это значит, что страничку текста освоить на порядки сложнее, чем проштудировать 10 учебников и задачников.

G>>>Ок, бери бета-редукцию. Примитивнее не придумаешь. Любому знающему арифметику можно объяснить за 2 минуты.

I>>Идёт. Мой сын которому скоро 5, как раз осваивает арифметику. Устроим сеанс мастер-класса, ты будешь объяснять ему бета редукцию. Не дай бог он этого не поймёт — пеняй на себя.
G>Данивопрос.

Проверим, как только он сможет выполнять действия на бумажке, я дам знать(если не забуду).
Re[37]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.10.12 08:49
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Я даже не пойму, куда там в учебник смотреть при проецировании. Разве что в залезть в википедию, подивиться на определение бетта-редукции, но мне кажется что 99% школьников могут обойтись без этого.


I>Они еще не доросли до этой абстракции, то есть она не была им нужна. Представь себе, абстракция не нужна для освоения самой себя. Абстракция это вобщем способ, с помощью которого мозг справляется с большим количеством информации.

В школе не нужно подставлять в формулу значения? Жжошь. Ты учился в школе для альтернативно одаренных?

I>"вовсе не нужен" Интерес это единсвтенный непосредственный мотиватор, и он дает наилучшие результаты при обучении, настолько лучшие, что по сравнению с ним отрицательной и положительной мотивацией можно пренебречь.

Я вижу что у тебя и твоих учеников и такого мотиватора не было, раз такие проблемы с проецированием в школе.

I>Но раз у тебя сложности с русским языком ("вовсе не нужен"), то тем нет смысла продолжать. Но по крайней мере ясно, откуда корни твоих передёргиваний, буду знать на будущее.

Бди за своим русским.
Re[38]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 08:59
Оценка:
Здравствуйте, samius, Вы писали:


I>>Они еще не доросли до этой абстракции, то есть она не была им нужна. Представь себе, абстракция не нужна для освоения самой себя. Абстракция это вобщем способ, с помощью которого мозг справляется с большим количеством информации.

S>В школе не нужно подставлять в формулу значения? Жжошь. Ты учился в школе для альтернативно одаренных?

Да, у меня в школе не было лямбда-счисления.

I>>"вовсе не нужен" Интерес это единсвтенный непосредственный мотиватор, и он дает наилучшие результаты при обучении, настолько лучшие, что по сравнению с ним отрицательной и положительной мотивацией можно пренебречь.

S>Я вижу что у тебя и твоих учеников и такого мотиватора не было, раз такие проблемы с проецированием в школе.

Только такой и был.
Re[39]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.10.12 09:15
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>В школе не нужно подставлять в формулу значения? Жжошь. Ты учился в школе для альтернативно одаренных?


I>Да, у меня в школе не было лямбда-счисления.

У меня тоже. А подстановка значений в формулу хотя бы была?

S>>Я вижу что у тебя и твоих учеников и такого мотиватора не было, раз такие проблемы с проецированием в школе.


I>Только такой и был.

Ну значит в некоторых случаях такой мотиватор не дает положительного результата. Накричи что ли на своих, замахнись, или побей разок если совсем туго. И попрет бета-редукция как встроенная. А педагогику оставь педагогам.
Re[23]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 09:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Контекст никуда не девается. Отсюда не ясно, где ты увидел произвольные трансформации, т.к. я показывал ровно тож самое что и в случае с шампанским.

Я увидел произвольные трансформации там, где вы пытаетесь привести повествовательное предложение в повелительное наклонение.
Если в случае с шампанским мы видим сокращённую форму предложения, которая подразумевает некоторый глагол (и то — глагол может быть разным!), то попытки превратить произвольное повествовательное предложение в некую инструкцию — это уже спекуляция.
Вот вы превратили пословицу "не всякий цветок даёт плод" в инструкцию. В следующий раз вы превратите фразу "Дует" не в "[Ветер] дует [в форточку]" (что вполне корректно), а в "Закрой форточку, дует" (что является спекуляцией).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[40]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 09:42
Оценка:
Здравствуйте, samius, Вы писали:

I>>Только такой и был.

S>Ну значит в некоторых случаях такой мотиватор не дает положительного результата. Накричи что ли на своих, замахнись, или побей разок если совсем туго. И попрет бета-редукция как встроенная. А педагогику оставь педагогам.

"накричи", "замахнись", "побей" — в 4м классе ни одно из этих средств не поможет с бета-редукций, но набор методов впечатляет, шикарное у тебя было детство, у то нас вот как то без битья и конфетки научились.
Re[24]: TMTOWTDI
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 09:46
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


I>>Контекст никуда не девается. Отсюда не ясно, где ты увидел произвольные трансформации, т.к. я показывал ровно тож самое что и в случае с шампанским.

S>Я увидел произвольные трансформации там, где вы пытаетесь привести повествовательное предложение в повелительное наклонение.

То есть вполне конкретное преобразование, а именно разворачивание свернутого выражения и изменение модальности, ты рассматриваешь как произвольное ? Я правильно тебя понял ?

S>Если в случае с шампанским мы видим сокращённую форму предложения, которая подразумевает некоторый глагол (и то — глагол может быть разным!), то попытки превратить произвольное повествовательное предложение в некую инструкцию — это уже спекуляция.


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

S>Вот вы превратили пословицу "не всякий цветок даёт плод" в инструкцию. В следующий раз вы превратите фразу "Дует" не в "[Ветер] дует [в форточку]" (что вполне корректно), а в "Закрой форточку, дует" (что является спекуляцией).


Я показал почему эта пословица есть императивная речь + продемонстрировал изменение модальности, а остальное это твои домыслы.
Re[41]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.10.12 09:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>"накричи", "замахнись", "побей" — в 4м классе ни одно из этих средств не поможет с бета-редукций, но набор методов впечатляет, шикарное у тебя было детство, у то нас вот как то без битья и конфетки научились.


Дык НЕ научились ведь, иначе что ты мне доказываешь?
Re[42]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 10:46
Оценка:
Здравствуйте, samius, Вы писали:

I>>"накричи", "замахнись", "побей" — в 4м классе ни одно из этих средств не поможет с бета-редукций, но набор методов впечатляет, шикарное у тебя было детство, у то нас вот как то без битья и конфетки научились.


S>Дык НЕ научились ведь, иначе что ты мне доказываешь?


Прикинь, как круто было бы — дал сразу лямбда-счисление и не надо 5 лет долбить уравнения, системы уравнений, задачи на упрощение выражений и тд и тд и тд.
Вобщем пиши трактат и становись в очередь на Нобелевку.
Re[25]: TMTOWTDI
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 10:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>То есть вполне конкретное преобразование, а именно разворачивание свернутого выражения и изменение модальности, ты рассматриваешь как произвольное ? Я правильно тебя понял ?

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

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

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

I>Я показал почему эта пословица есть императивная речь + продемонстрировал изменение модальности, а остальное это твои домыслы.

Нет, вы привели свои домыслы по поводу того, как построить императивное утверждение, которое нетривиальным образом связано с исходным.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[43]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.10.12 11:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Дык НЕ научились ведь, иначе что ты мне доказываешь?


I>Прикинь, как круто было бы — дал сразу лямбда-счисление и не надо 5 лет долбить уравнения, системы уравнений, задачи на упрощение выражений и тд и тд и тд.

Не знаю, что вы там 5 лет долбили, если подставлять значения не научились.
I>Вобщем пиши трактат и становись в очередь на Нобелевку.
То что для тебя достойно нобелевки — обыкновенное дело для среднего школьника, даже не битого математичкой.
Re[11]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 03.10.12 11:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:


I>В автомобиле нужно знать внутреннее устройство с определенной степенью детализации. Если ты просто расскажешь и покажешь двигатель и колеса, то ничего ты не добьёшься. Нужна вполне адекватная модель — руль, гидроусилитель, колеса, коробка передач, трансмиссия, подвеска, проводка, зажигания и связи между ними. Все это, повторяясь, внутреннее устройство, только с определенным уровнем детализации.

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

На самом деле всё ещё хуже — реальное внутреннее устройство автомобиля вообще неизвестно почти никому, кроме автомехаников.
Нарисованная в голове "знатока" картинка руля — гидроусилителя — рулевой рейки значительно упрощена с отбрасыванием массы существенных деталей — например, механизма подруливания задними колёсами, который отличает поворот от перестроения.
Механизм работы автоматической трансмиссии — это вообще rocket science. Помнится, в Популярной Механике была про это статья. Ровно после этого я бросил читать этот журнал, т.к. всё "объяснение" там сводилось к "ну, там унутре шестерёнки, которые крутятся".
Моя жена знает про АТ ещё меньше меня. И это абсолютно не мешает ей прекрасно водить машину.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 11:55
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Определённая степень детализации — это ровно "наблюдаемое поведение".

S>Блондинка понятия не имеет, как устроен гидроусилитель, и что он вообще есть. Ей достаточно знать, что когда поворачиваешь руль вправо — машинка тоже поворачивает вправо. Всё, на этом необходимая детализация заканчивается.

Это самое "наблюдаемое поведение" начинают наблюдать примерно с тех пор, когда берут в руки игрушки, велосипеды, самокаты и тд и тд. Продолжается это на уроках физики, дальше появляется опыт как пассажира. В итоге у всех современных людей в голове уже сформирована более-менее адекватная модель с нужной степенью детализации.
И при этом я нигде не утверждаю, что надо знать авто на уровне автомеханика.
Re[44]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 03.10.12 12:21
Оценка:
Здравствуйте, samius, Вы писали:

I>>Прикинь, как круто было бы — дал сразу лямбда-счисление и не надо 5 лет долбить уравнения, системы уравнений, задачи на упрощение выражений и тд и тд и тд.

S>Не знаю, что вы там 5 лет долбили, если подставлять значения не научились.

"В 4м они делают все руками, а надо дождаться пока все это не начнут делать в уме автоматически, а на это нужно очень много времени."
С выделенным текстом всё понятно ?

Еще раз — если ты умеешь подставить 2 в a + 2 и получить 4 то это не тоже самое, что ты освоил бета редукцию.
То есть, ни много ни мало, нужно ждать пока человек не научится упрощать и вычислять выражения в уме, причем
1 за очень короткое время
2 без ошибок
Вот тогда можно сказать он готов к лямбда счислению тому же.

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

Попробуй на досуге посмотреть результаты выпускных или вступительных экзаментов по математике российских школьников/абитуриентов, узнаешь много нового на тему, как школьники "свободно" владеют этой подстановкой. Чуть не все ошибки в вычислениях это ошибки в подстановках и упрощении выражений. Брошеные на пол-пути вычисления — тоже самое, слишком много времени тратят на ошибки и вычисления.
Собственно не нужно удивляться, почему в школе очень много времени удивляется всяким задачам на упрощение выражений.

Вобщем, продолжай хамить дальше, у тебя это хорошо получается.
Re[45]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 03.10.12 12:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:



S>>Не знаю, что вы там 5 лет долбили, если подставлять значения не научились.


I>"В 4м они делают все руками, а надо дождаться пока все это не начнут делать в уме автоматически, а на это нужно очень много времени."

I>С выделенным текстом всё понятно ?
Как раз не все. Автоматически — это не приходя в сознание что ли? И я-то так не умею. Если не вожу пальцами по экрану, одним в формулу, другим в значение, то это не значит что я достиг автоматизма.

I>Еще раз — если ты умеешь подставить 2 в a + 2 и получить 4 то это не тоже самое, что ты освоил бета редукцию.

I>То есть, ни много ни мало, нужно ждать пока человек не научится упрощать и вычислять выражения в уме, причем
I>1 за очень короткое время
I>2 без ошибок
I>Вот тогда можно сказать он готов к лямбда счислению тому же.
Ошибки делают все, даже те кто изучил лямбда-счисление. И за рулем тоже, если что.

I>Когда дети строят графики функций на такие вычисления у них уходит очень много времени, поэтому все то, чем важна бета-редукция в лямбда-счислении, останется в стороне.

Чем она важна кроме того что это и есть подстановка?

I>Попробуй на досуге посмотреть результаты выпускных или вступительных экзаментов по математике российских школьников/абитуриентов, узнаешь много нового на тему, как школьники "свободно" владеют этой подстановкой. Чуть не все ошибки в вычислениях это ошибки в подстановках и упрощении выражений. Брошеные на пол-пути вычисления — тоже самое, слишком много времени тратят на ошибки и вычисления.

I>Собственно не нужно удивляться, почему в школе очень много времени удивляется всяким задачам на упрощение выражений.
А упрощать не нужно. Нужно подставить и вычислить. Можно даже не подставлять и вычислять, а тупо нарисовать стрелку: x -> f(x). Тут даже ошибиться негде.

I>Вобщем, продолжай хамить дальше, у тебя это хорошо получается.

Польщен

Но я обсуждаю с тобой не перспективы внедрения в школьную программу 4го класса лямбда-счисления. Я обсуждаю с тобой наличие в школьной программе (безотносительно классов) концепций, позволяющей понять суть map.
Re[46]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 08:11
Оценка:
Здравствуйте, samius, Вы писали:

I>>С выделенным текстом всё понятно ?

S>Как раз не все. Автоматически — это не приходя в сознание что ли? И я-то так не умею. Если не вожу пальцами по экрану, одним в формулу, другим в значение, то это не значит что я достиг автоматизма.

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


I>>Вот тогда можно сказать он готов к лямбда счислению тому же.

S>Ошибки делают все, даже те кто изучил лямбда-счисление. И за рулем тоже, если что.

Идеального эталона не существует. Это все что ты хотел сказать или была какая более глубокая мысль ?

I>>Когда дети строят графики функций на такие вычисления у них уходит очень много времени, поэтому все то, чем важна бета-редукция в лямбда-счислении, останется в стороне.

S>Чем она важна кроме того что это и есть подстановка?

Дает полноту по тьюрингу.

I>>Собственно не нужно удивляться, почему в школе очень много времени удивляется всяким задачам на упрощение выражений.

S>А упрощать не нужно. Нужно подставить и вычислить. Можно даже не подставлять и вычислять, а тупо нарисовать стрелку: x -> f(x). Тут даже ошибиться негде.

(\x. x x x) (\x. x x x)

Валяй.

I>>Вобщем, продолжай хамить дальше, у тебя это хорошо получается.

S>Польщен

S>Но я обсуждаю с тобой не перспективы внедрения в школьную программу 4го класса лямбда-счисления. Я обсуждаю с тобой наличие в школьной программе (безотносительно классов) концепций, позволяющей понять суть map.


А по моему ты просто хамишь, т.к. никаких аргументов на этом фоне не заметно.
Re[47]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 08:48
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>С выделенным текстом всё понятно ?

S>>Как раз не все. Автоматически — это не приходя в сознание что ли? И я-то так не умею. Если не вожу пальцами по экрану, одним в формулу, другим в значение, то это не значит что я достиг автоматизма.

I>

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

А где тут логические операции?

S>>Ошибки делают все, даже те кто изучил лямбда-счисление. И за рулем тоже, если что.


I>Идеального эталона не существует. Это все что ты хотел сказать или была какая более глубокая мысль ?

Я хотел сказать что нет смысла ждать пока кто-то перестанет ошибаться. Собственно это и не практикуется ни в школе ни в вузе.

I>>>Когда дети строят графики функций на такие вычисления у них уходит очень много времени, поэтому все то, чем важна бета-редукция в лямбда-счислении, останется в стороне.

S>>Чем она важна кроме того что это и есть подстановка?

I>Дает полноту по тьюрингу.

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

S>>А упрощать не нужно. Нужно подставить и вычислить. Можно даже не подставлять и вычислять, а тупо нарисовать стрелку: x -> f(x). Тут даже ошибиться негде.


I>(\x. x x x) (\x. x x x)


I>Валяй.

Держи
(\x.xxx)(\x.xxx)(\x.xxx)

S>>Но я обсуждаю с тобой не перспективы внедрения в школьную программу 4го класса лямбда-счисления. Я обсуждаю с тобой наличие в школьной программе (безотносительно классов) концепций, позволяющей понять суть map.


I>А по моему ты просто хамишь, т.к. никаких аргументов на этом фоне не заметно.

А чем еще мне заняться? Ведь по сути ты со мной согласился, но продолжаешь возражать каждой букве. Абстракция для map в школе дана, и не надо лезть мне под кожу с лямбда счислением в 4м классе.
Re[14]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 08:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну так вот наблюдаемое поведение алгебраических абстракций начинают наблюдать примерно с пятого класса. И к первому курсу мы вправе ожидать от произвольного студента способности хотя бы подставить x*y вместо a в выражении (a + b)^2 = a^2 + 2ab + b^2.

S>Все необходимые навыки для освоения программирования уже есть.

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

S>Человека, который знает про машину ровно столько, сколько можно узнать при освоении детской тележки с колёсиками, обучают вождению за 30 часов.


S>Человека, который в качестве базиса имеет школьный курс математики, крайне тяжело научить императивному программированию.


Наоборот, проще простого. Это самое императивное программирование многие начинают осваивать примерно в 4-6м классе. Со мной както работал чел, который начал программировать ажно в 3м классе. Зато не знаю ни одного человека, который бы начал программировать в 4-6м да сразу с функциональщины.

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

S>Потому что он не имеет никакого опыта работы с "абстрактным вычислителем".

S>По моему опыту работы с непрофильными студентами первых курсов, концепции "переменной" вызывают значительный баттхёрт.

У непрофильных наверняка и с математикой проблемы были серьёзные.

S>Просто потому, что в школе x = 2 + a и x — a = 2 — одно и то же, и этому обучают пять лет подряд.

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

Указатель дается тяжело, а вот ссылка — очень просто. Потому например во многих вузах используют для обучения Питон а уже потом дают Си с указателями.

S>После того, как вы объяснили людям указатели, вы пытаетесь дать им рекурсию, и начинается взрыв мозга, потому что x теперь одновременно хранит несколько значений. И вам нужен стек, и ещё много всего.


Нет никакого взрыва мозга. Нужно правильно дать задачу. см лекции в МИТ. На пост-СССР пространстве преподаватели почему так не умеют и не хотят

S>Да, в итоге на некоторых из жертв снисходит озарение, и картинка внезапно складывается.

S>Но к моменту, когда это произошло, их одноклассники, посаженные за Excel, уже не только освоили декларативное программирование, а наколбасили на нём тонны прикладных решений.

Я даже знаю много таких примеров, люди колбасят свои вычислялки пачками. Эксель это вообще ничего, пустое место то есть.
Пусть решат в экселе скажем какую задачку по физике или электротехнике, где нужен итерационный алгоритм или энергетический, поглядим чего у них выйдет.
Re[14]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 08:55
Оценка:
Здравствуйте, Курилка, Вы писали:

К>Вот ещё одно мнение, о том, что ваше "у всех" не совсем наблюдается в реальности.


Неправильный подход в обучении. Составлять и выполнять пошаговые инструкции умеют, а "пошагово выполнять" что либо не умеют — загадка.

Мой сын вот знает, как пользоваться инструкцией по сборке авто из конструктора и знает, что пропускать шаги нельзя. Вобщем у тебя по ссылке какие то кошмары
Re[15]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 04.10.12 09:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ну я бы не был так уверен, глядя на ошибки в вычислениях у абитуриентов или даже студентов, когда они скажем электротехнику решают

Ошибки есть у всех. Если у вас есть QA отдел, то сходите туда, и вам быстро развеют любые иллюзии про качество кода, даже написанного senior developer-ами.
Вопрос не в том, как построить безошибочную машину по написанию кода, а в том, чтобы человек начал приносить пользу.

I>Наоборот, проще простого. Это самое императивное программирование многие начинают осваивать примерно в 4-6м классе. Со мной както работал чел, который начал программировать ажно в 3м классе. Зато не знаю ни одного человека, который бы начал программировать в 4-6м да сразу с функциональщины.

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

I>Тяжело дается освоение библиотек, вот это действительно тяжело. Надо понимать ввод-вывод и свойства вычислителя.

Омг. Библиотеки — это всего лишь библиотеки. Свойства вычислителя тут нужны ровно потому, что речь об императиве, и он сложен, т.к. у непрограммиста нет в голове нужных абстракций.

I>В функциональном, что характерно, ровно те же проблемы, только функциональщину раньше окончания школы сильно вряд ли можно скормить. Многим даже после окончания вуза она в голову не лезет.

Наблюдения не подтверждают этого утверждения.

I>У непрофильных наверняка и с математикой проблемы были серьёзные.

Неа. Я говорю о студентах первого курса ММФ НГУ.

I>Указатель дается тяжело, а вот ссылка — очень просто. Потому например во многих вузах используют для обучения Питон а уже потом дают Си с указателями.

Нет. Ссылка даётся ровно так же тяжело.
I>Нет никакого взрыва мозга. Нужно правильно дать задачу. см лекции в МИТ. На пост-СССР пространстве преподаватели почему так не умеют и не хотят
Одно из двух: либо преподаватели неправильные, либо императив требует от человека освоения чуждых ему концепций.

I>Я даже знаю много таких примеров, люди колбасят свои вычислялки пачками. Эксель это вообще ничего, пустое место то есть.

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

I>Пусть решат в экселе скажем какую задачку по физике или электротехнике, где нужен итерационный алгоритм или энергетический, поглядим чего у них выйдет.

Вы приведите пример задачи, а там посмотрим — нужен ли вообще "итерационный алгоритм", или у вас травма от императивного программирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 09:40
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Ну я бы не был так уверен, глядя на ошибки в вычислениях у абитуриентов или даже студентов, когда они скажем электротехнику решают

S>Ошибки есть у всех. Если у вас есть QA отдел, то сходите туда, и вам быстро развеют любые иллюзии про качество кода, даже написанного senior developer-ами.
S>Вопрос не в том, как построить безошибочную машину по написанию кода, а в том, чтобы человек начал приносить пользу.

Ошибки есть у всех, но у всех разное количетсво. У одного по ошибке на строчку, у другого по ошибке на файл, у третьего — по ошибке на коммит. Берем самого лучшего за эталон и все становится просто.

I>>Наоборот, проще простого. Это самое императивное программирование многие начинают осваивать примерно в 4-6м классе. Со мной както работал чел, который начал программировать ажно в 3м классе. Зато не знаю ни одного человека, который бы начал программировать в 4-6м да сразу с функциональщины.

S>О, как интересно. То есть пример этого отдельного человека уже считается доказательством победы императивного над разумным?

Я не предлагаю начинать учить програмимрованию в 3м классе. Что касается примернов, то про 3й клас у меня он единственный да. А вот люди, которые начинали в 4-6м встречается на собеседованиях относительно часто.

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


А ты по прежнему похмеляешься коньяком ?

I>>Тяжело дается освоение библиотек, вот это действительно тяжело. Надо понимать ввод-вывод и свойства вычислителя.

S>Омг. Библиотеки — это всего лишь библиотеки. Свойства вычислителя тут нужны ровно потому, что речь об императиве, и он сложен, т.к. у непрограммиста нет в голове нужных абстракций.

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

I>>В функциональном, что характерно, ровно те же проблемы, только функциональщину раньше окончания школы сильно вряд ли можно скормить. Многим даже после окончания вуза она в голову не лезет.

S>Наблюдения не подтверждают этого утверждения.

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

I>>У непрофильных наверняка и с математикой проблемы были серьёзные.

S>Неа. Я говорю о студентах первого курса ММФ НГУ.

А почему вдруг они стали непрофильными ?

I>>Указатель дается тяжело, а вот ссылка — очень просто. Потому например во многих вузах используют для обучения Питон а уже потом дают Си с указателями.

S>Нет. Ссылка даётся ровно так же тяжело.

Я думаю дело в подходе к обучению.

I>>Нет никакого взрыва мозга. Нужно правильно дать задачу. см лекции в МИТ. На пост-СССР пространстве преподаватели почему так не умеют и не хотят

S>Одно из двух: либо преподаватели неправильные, либо императив требует от человека освоения чуждых ему концепций.

Преподаватели. Императив требует тоже самое что и функциональщина и программирование вообще — освоение вычислителя.

I>>Я даже знаю много таких примеров, люди колбасят свои вычислялки пачками. Эксель это вообще ничего, пустое место то есть.

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

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

I>>Пусть решат в экселе скажем какую задачку по физике или электротехнике, где нужен итерационный алгоритм или энергетический, поглядим чего у них выйдет.

S>Вы приведите пример задачи, а там посмотрим — нужен ли вообще "итерационный алгоритм", или у вас травма от императивного программирования.

Нужен, не боись, это не я придумал.
Re[48]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 10:26
Оценка:
Здравствуйте, samius, Вы писали:

I>>

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

S>А где тут логические операции?

Здесь не имеется ввиду операции из алгебры логики

I>>Идеального эталона не существует. Это все что ты хотел сказать или была какая более глубокая мысль ?

S>Я хотел сказать что нет смысла ждать пока кто-то перестанет ошибаться. Собственно это и не практикуется ни в школе ни в вузе.

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

I>>(\x. x x x) (\x. x x x)

I>>Валяй.
S>Держи
S>(\x.xxx)(\x.xxx)(\x.xxx)

И что получилось ?

I>>А по моему ты просто хамишь, т.к. никаких аргументов на этом фоне не заметно.

S>А чем еще мне заняться?

Каждый решает сам, то есть поступает по своей природе
Re[11]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.10.12 11:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


>>Да, для map надо рекурсивные функции и рекурсивные структуры данных объяснить. Дело двух занятий. Если же пойти по пути объяснения с битов, байтов и машинных команд, то к map и за два года не придешь.


I>Не смеши людей

Это к чему? У тебя другое мнение? Аргументировать можешь? Я рекурсивные функции могу за 2 часа объяснить. ФВП еще за час. Рекурсивные структуры данных — тоже два часа.
Причем я все это делал. Как ты думаешь, долго еще до map? Без углублений в теорию и типы данных это все очень простые концепции, в разы проще чем МТ.

Кстати в МТ композиция — охренительно сложная тема. Я в универском курсе еле осилил. Композиция функций — элементарщина.

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


I>Это плохой пример.Тебе кажется, что с авто всё очень просто. Между тем внутреннее устройство автомобиля изучается например на уроках физики, неявно а косвенно — двигатель, тормоза, проводка, есть буквально строятся модели которые применимы и к автомобилю. В ряде случаев так и вовсе берутся примеры-задачи прямо относящиеся к автомобилю.

Да-да, я как раз об этом и говорю. Для того чтобы ездить мне все это не надо знать. Надо только понимать что двигатель соединен с колесами и как работает сцепление.

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

Совершенно необязательно. У меня куча контр-примеров. Люди много лет ездят и не знают что такое подшипник.

I>В автомобиле нужно знать внутреннее устройство с определенной степенью детализации. Если ты просто расскажешь и покажешь двигатель и колеса, то ничего ты не добьёшься. Нужна вполне адекватная модель — руль, гидроусилитель, колеса, коробка передач, трансмиссия, подвеска, проводка, зажигания и связи между ними. Все это, повторяясь, внутреннее устройство, только с определенным уровнем детализации.

Че? Ты в автошколе давно был? Там гораздо примитивнее объясняется, и то этого много. При наличии всяких ABS и автоматических коробок передач вообще не надо знать устройства автомобиля.


I>В программировании ничего подобного нет и быть не может, это осваивается буквально с нуля, т.к. математика сама по себе "не работает".

Я не понял что с чем ты сравниваешь. Одно заблуждение с другим?
Re[17]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 11:15
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>А причем тут машина тьюринга? Для написания программ, работающих на CLR нужно знание\понимание машины тьюринга? У меня куча обратных примеров.


Для сравнения. Более менее адекватную модель вычислителя придется освоить, иначе программирования не получится.

I>>Потому что лямбда-счисление это очень высокоуровневая абстракция.

G>Высоко- или низко- уровневость определяется относительно. Когда идет начальное обучение и мозг не засорен другими моделями, то имеет смысл как раз обучать на высокоуровневых абстракциях.

Эти абстракции нужно выращивать,а не спускать сверху. Попробуй применить свой пример ан практике, например — дать матан в 3м классе. Ну, раз есть смысла обучать на высокоуровневых абстракциях, все должно прокатить на раз.

I>>Пойми простую вещь — математику осваивают с палочек.

G>Доказательство по аналогии? Не прокатило.

Иллюстрация. Все осваивается начиная с "пощупать" + "посмотреть". Вообще всё. Исключения — способности вложеные в тебя в виде кое какие безусловных рефлексов.

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


Первая проблема — дать пригодную модель вычислителя . Дальше её нужно будет улучшать, что бы она справлялась с более сложными задачами. Для этого нужно сделать так, что бы ученик мог "пощупать" и "посмотреть" программу на задачах которые ему отлично понятны. То есть, процесс обучения получается таким Ж
Задача 1 + пощупать + посмотреть -> концепция 1, задача 2 + пощупать + посмотреть-> концепция 2, задача N + пощупать + посмотреть -> концепция N

I>>Например зная ВМ весь школьный курс можно уложить примерно в страничку текста. Это значит, что страничку текста освоить на порядки сложнее, чем проштудировать 10 учебников и задачников.

G>ВМ опирается на школьный курс, лямбда исчисление не опирается на машину тьюринга. Подумай над этим.

возьми эксель и запрограммируй в ём какой нибудь энергетический алгоритм размещения графа.
Re[12]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 11:59
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Не смеши людей

G>Это к чему? У тебя другое мнение? Аргументировать можешь? Я рекурсивные функции могу за 2 часа объяснить. ФВП еще за час. Рекурсивные структуры данных — тоже два часа.

Верю. А за какое время студенты смогут освоить все это до уровня свободного владения ?

G>Причем я все это делал. Как ты думаешь, долго еще до map? Без углублений в теорию и типы данных это все очень простые концепции, в разы проще чем МТ.


Объяснения не интересуют. Важно время на то, что бы попробовать все вещи руками, то есть, освоить вычислитель, что бы более менее адекватная моделька сложилась в голове.

G>Да-да, я как раз об этом и говорю. Для того чтобы ездить мне все это не надо знать. Надо только понимать что двигатель соединен с колесами и как работает сцепление.


Ну то есть этого знать не надо, но только это и надо понимать. Опаньки !

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

G>Совершенно необязательно. У меня куча контр-примеров. Люди много лет ездят и не знают что такое подшипник.

Термина вполне возможно и не знают.

G>Че? Ты в автошколе давно был? Там гораздо примитивнее объясняется, и то этого много. При наличии всяких ABS и автоматических коробок передач вообще не надо знать устройства автомобиля.


Ты вероятно думаешь, будто я утверждаю, что надо знать устройство не хуже автомеханика или вообще конструктора ?
Re[49]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 12:15
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>А где тут логические операции?


I>Здесь не имеется ввиду операции из алгебры логики

А откуда?
Ну вот например,

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

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

I>Наоборот, надо ждать до тех пор, пока ученик не выйдет на должный уровень по скорости/качеству. Если некоторую операцию ты выполняешь пять минут или с десятком ошибком, то сильно вряд ли ты освоишь вещь, где эта операция встречается повсеместно.

Вряд ли — это слишком сильно. Регулярно приходилось осваивать и на одном понимании без механического заучивания.

S>>Держи

S>>(\x.xxx)(\x.xxx)(\x.xxx)

I>И что получилось ?

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

I>>>А по моему ты просто хамишь, т.к. никаких аргументов на этом фоне не заметно.

S>>А чем еще мне заняться?

I>Каждый решает сам, то есть поступает по своей природе

Возразить нечего. Кроме того что не последил бы ты за своей природой, которая имеет тенденцию переводить обсуждение к природе оппонента.
Re[18]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 04.10.12 12:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>А причем тут машина тьюринга? Для написания программ, работающих на CLR нужно знание\понимание машины тьюринга? У меня куча обратных примеров.


I>Для сравнения. Более менее адекватную модель вычислителя придется освоить, иначе программирования не получится.

Бета-редукция более чем адекватна. Я не пойму чем она тебя не устраивает.


I>>>Потому что лямбда-счисление это очень высокоуровневая абстракция.

G>>Высоко- или низко- уровневость определяется относительно. Когда идет начальное обучение и мозг не засорен другими моделями, то имеет смысл как раз обучать на высокоуровневых абстракциях.

I>Эти абстракции нужно выращивать,а не спускать сверху. Попробуй применить свой пример ан практике, например — дать матан в 3м классе. Ну, раз есть смысла обучать на высокоуровневых абстракциях, все должно прокатить на раз.

Доказательство во по аналогии снова не прокатило. Матан опирается на арифметику, лямбда-исчисление не опирается на машину тьюринга.

Кстати в большинстве учебных заведений начинают с блок-схем. Они также не зависят ни от машин тьюрига, ни от лямбда-исчисления.



I>>>Пойми простую вещь — математику осваивают с палочек.

G>>Доказательство по аналогии? Не прокатило.

I>Иллюстрация. Все осваивается начиная с "пощупать" + "посмотреть". Вообще всё. Исключения — способности вложеные в тебя в виде кое какие безусловных рефлексов.

Иллюстрация вообще не в тему. Мыслительные процессы работают не так как тактильные.

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


I>Первая проблема — дать пригодную модель вычислителя . Дальше её нужно будет улучшать, что бы она справлялась с более сложными задачами.

Именно: бета-редукция -> вычисление с окружениями -> регистровая машина\стековая машина.

I>Для этого нужно сделать так, что бы ученик мог "пощупать" и "посмотреть" программу на задачах которые ему отлично понятны. То есть, процесс обучения получается таким Ж

I>Задача 1 + пощупать + посмотреть -> концепция 1, задача 2 + пощупать + посмотреть-> концепция 2, задача N + пощупать + посмотреть -> концепция N
Насчет "пощупать и посмотреть" — непонятно что это означает в плане мыслительного процесса.

I>>>Например зная ВМ весь школьный курс можно уложить примерно в страничку текста. Это значит, что страничку текста освоить на порядки сложнее, чем проштудировать 10 учебников и задачников.

G>>ВМ опирается на школьный курс, лямбда исчисление не опирается на машину тьюринга. Подумай над этим.
I>возьми эксель и запрограммируй в ём какой нибудь энергетический алгоритм размещения графа.
Это тут к чему? Пытаешься перевести тему?
Re[50]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 13:02
Оценка:
Здравствуйте, samius, Вы писали:

S>Покажи как в бета-редукции порождаются новые понятия. Или уточни, о каких таких логических операциях та цитата.


подстановка и есть эта самая операция. В умственные навыки превращается не только алгебра логики

S>>>Держи

S>>>(\x.xxx)(\x.xxx)(\x.xxx)

I>>И что получилось ?

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

Среднюю школу заканчивают в 4м классе или нет ?
Re[19]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 13:13
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Для сравнения. Более менее адекватную модель вычислителя придется освоить, иначе программирования не получится.

G>Бета-редукция более чем адекватна. Я не пойму чем она тебя не устраивает.

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

I>>Эти абстракции нужно выращивать,а не спускать сверху. Попробуй применить свой пример ан практике, например — дать матан в 3м классе. Ну, раз есть смысла обучать на высокоуровневых абстракциях, все должно прокатить на раз.

G>Доказательство во по аналогии снова не прокатило. Матан опирается на арифметику, лямбда-исчисление не опирается на машину тьюринга.

Вообще говоря "арифметику" можно вывести из теории категорий по моему. Значит что бы не давать арифметику, даем сразу терию категорий.
Пример попроще — вместо того, что бы решать задачи на объём и площадь, лучше взять да изучить сразу интеграл — резко появится отличный инструмент для решения задач на объем и площадь.

G>Кстати в большинстве учебных заведений начинают с блок-схем. Они также не зависят ни от машин тьюрига, ни от лямбда-исчисления.


Честно — мне такие учебные заведения не известны. Начинают или с Си, или с Паскаля, или с Питона, или со Схемы, или с ассемблера. Других вещей не встречал.

I>>Иллюстрация. Все осваивается начиная с "пощупать" + "посмотреть". Вообще всё. Исключения — способности вложеные в тебя в виде кое какие безусловных рефлексов.

G>Иллюстрация вообще не в тему. Мыслительные процессы работают не так как тактильные.

Конечно не так, зато любая деятельность осваивается через сенсомоторную стадию. то есть "пощупать" и "посмотреть".
Повторю — любая. За доказательствами смотри в сторону когнитивной психологии.

I>>Первая проблема — дать пригодную модель вычислителя . Дальше её нужно будет улучшать, что бы она справлялась с более сложными задачами.

G>Именно: бета-редукция -> вычисление с окружениями -> регистровая машина\стековая машина.

Не вычисление с окружениями, а особенности конкретного вычислителя, время, ресурсы, состояние и тд и тд.
Вот здесь хорошая иллюстрация : http://worrydream.com/LearnableProgramming/

I>>Задача 1 + пощупать + посмотреть -> концепция 1, задача 2 + пощупать + посмотреть-> концепция 2, задача N + пощупать + посмотреть -> концепция N

G>Насчет "пощупать и посмотреть" — непонятно что это означает в плане мыслительного процесса.

Это значит, что ты сначала трогаешь нечто пальцем, смотришь на реакцию и делаешь вывод. Снова трогаешь, снова смотришь, снова делаешь вывод.

G>>>ВМ опирается на школьный курс, лямбда исчисление не опирается на машину тьюринга. Подумай над этим.

I>>возьми эксель и запрограммируй в ём какой нибудь энергетический алгоритм размещения графа.
G>Это тут к чему? Пытаешься перевести тему?

Это тоже самое. Запрограммируй, а потом посмотрим, что да как.
Re[14]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 13:23
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Верю. А за какое время студенты смогут освоить все это до уровня свободного владения ?

G>Если голый рассказ дополнить практикой в том же объеме, то достаточно. По универским метрикам — 5 теоретических и 5 практических занятий будет достаточно.

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

I>>Объяснения не интересуют. Важно время на то, что бы попробовать все вещи руками, то есть, освоить вычислитель, что бы более менее адекватная моделька сложилась в голове.

G>Как ты собрался МТ руками пробовать? Я не пойму о чем ты.

Необязательно непосредсвтенный контакт. Можно и опосредовано. Весь абстрактный опыт именно так и накапливается.

G>>>Да-да, я как раз об этом и говорю. Для того чтобы ездить мне все это не надо знать. Надо только понимать что двигатель соединен с колесами и как работает сцепление.

I>>Ну то есть этого знать не надо, но только это и надо понимать. Опаньки !
G>Нет, всего остального знать не надо, да и это необязательно.

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

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

G>>>Совершенно необязательно. У меня куча контр-примеров. Люди много лет ездят и не знают что такое подшипник.
I>>Термина вполне возможно и не знают.
G>Конструкции и подавно

Главное что бы модель была внятная, иначе ты даже задачу механику внятно не сможешь поставить

I>>Ты вероятно думаешь, будто я утверждаю, что надо знать устройство не хуже автомеханика или вообще конструктора ?

G>Я слабо понимаю что ты утверждаешь, но я утверждаю что для вождения современного автомобиля вообще не надо знать его устройство.

Устройство == модель с определенной степенью детализации. Для начала хватит и так — есть колеса, значит это может ехать, есть руль, значит это может поворачивать. Но только для начала.
Re[51]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 13:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Покажи как в бета-редукции порождаются новые понятия. Или уточни, о каких таких логических операциях та цитата.


I>подстановка и есть эта самая операция. В умственные навыки превращается не только алгебра логики

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

I>>>И что получилось ?

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

I>Среднюю школу заканчивают в 4м классе или нет ?

Чего ты прицепился к 4-му классу? Я тебе пишу про окончание школы, а ты мне про 4ый класс. Не дают покоя детки, рисующие зверят по координатам в 4м классе?
Re[18]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 13:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Я не предлагаю начинать учить програмимрованию в 3м классе. Что касается примернов, то про 3й клас у меня он единственный да. А вот люди, которые начинали в 4-6м встречается на собеседованиях относительно часто.

S>Тогда зачем вы постоянно сбиваетесь на то, что для ФП нужны концепции, которые начинают изучать в пятом?

Ты перестал пить палёную водку ? Самиус, а не я, говорит что для ФП достаточно вещей которые проходят в 4-5м классе.

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


А ты хотел что бы все вопросы обучения брались из книги Кнута ?

S>Внезапно оказывается, что ваши школьники уже умеют "составлять инструкции", хотя их этому никто не учит.


Правильно. Разумеется не любые инструкции. Любые никто вообще в мире не умеет

>Зато "подставлять выражения в формулу" они у вас же не умеют, несмотря на то, что их этому учат с 5го по 11й класс.


Вычислил правильно и времени хватило — значит умеет. Вычислил правильно, но времени потратил больше чем было — не умеет. Вычислил неправильно — не хватило. Берешь и смотришь решения задач из тех, кто ошибки в вычислениях, делаешь выводы.

I>>Я думаю дело в подходе к обучению.

S>А я думаю, что проще учить программированию постепенно, а не начиная с самых противоестественных для обычного человека концепций.

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

Вобщем покажи хороший аналог подхода для обучения, http://worrydream.com/LearnableProgramming/, но что бы никакой императивщины.

I>>Преподаватели. Императив требует тоже самое что и функциональщина и программирование вообще — освоение вычислителя.

S>ФП не требует никакого освоения вычислителя. По крайней мере, на начальных этапах.

см выше

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

S>Отличная задача по электротехнике. 99% знакомых мне императивных программистов провозятся не один месяц над решением этой задачи.
S>Потому что тут вопрос не в программировании, а в математике

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

I>>Нужен, не боись, это не я придумал.

S>А, ну тогда не вам дадут премию Тьюринга. Теорему Чёрча не каждый день опровергают.

Это не опровержение, а указание на свойства экселя. Теоретически в ём можно всё. А на практике тебе может не хватить строчек или ячеек.
Re[52]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 13:53
Оценка:
Здравствуйте, samius, Вы писали:

I>>подстановка и есть эта самая операция. В умственные навыки превращается не только алгебра логики

S>Щас мы договоримся что и покраска забора тоже логическая операция, выражающийся в подставлении забора под краску и никак не решающийся в 4м классе.

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

I>>Среднюю школу заканчивают в 4м классе или нет ?

S>Чего ты прицепился к 4-му классу? Я тебе пишу про окончание школы, а ты мне про 4ый класс.

Раз ты отбросил свою идею про 4й класс, то можно и закончить.
Re[53]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 14:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>подстановка и есть эта самая операция. В умственные навыки превращается не только алгебра логики

S>>Щас мы договоримся что и покраска забора тоже логическая операция, выражающийся в подставлении забора под краску и никак не решающийся в 4м классе.

I>И давно у тебя покраска забора вдруг стала "сложная сознательная психическая деятельность" ? Чисто ради интереса, может тебе делали операцию какую и обнаружили "там" заборы

Давно. Сложная — не каждый справится. Сознательная — не видел что бы это делали не приходя в сознание. Психическая — очень. Если переборщишь с покраской заборов, психануть можно. Операцию может и делали какую, но что там обнаружили мне не докладывали. Да и твоя ли это забота?

I>>>Среднюю школу заканчивают в 4м классе или нет ?

S>>Чего ты прицепился к 4-му классу? Я тебе пишу про окончание школы, а ты мне про 4ый класс.

I>Раз ты отбросил свою идею про 4й класс, то можно и закончить.

Это была твоя идея. Я про 4ый класс говорил лишь то, что рисовал зверят по координатам.
Re[54]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 14:52
Оценка:
Здравствуйте, samius, Вы писали:

I>>И давно у тебя покраска забора вдруг стала "сложная сознательная психическая деятельность" ? Чисто ради интереса, может тебе делали операцию какую и обнаружили "там" заборы

S>Давно. Сложная — не каждый справится. Сознательная — не видел что бы это делали не приходя в сознание.

Ты не правильно понимаешь этот термин.

>Психическая — очень. Если переборщишь с покраской заборов, психануть можно.


И этот тоже.

>Операцию может и делали какую, но что там обнаружили мне не докладывали. Да и твоя ли это забота?


Извини, не буду у тебя хлеб отбирать

I>>Раз ты отбросил свою идею про 4й класс, то можно и закончить.

S>Это была твоя идея. Я про 4ый класс говорил лишь то, что рисовал зверят по координатам.

Нет, не моя. Это ж ты с проекцией да с бета-редукцией носился, а я как раз говорил и говорю что раньше окончания школы основной массе в программухе делать нечего.
Re[55]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 15:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Ты не правильно понимаешь этот термин.

I>И этот тоже.
А ты неправильно понимаешь мои подколки.

S>>Это была твоя идея. Я про 4ый класс говорил лишь то, что рисовал зверят по координатам.


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

Ну т.е. ты все это время спорил с голосами, ведь я и не настаивал что в школе надо программуху давать. Я лишь говорил что все что надо для map там уже дадено и отработано до мозолей в мозге.
Re[56]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.10.12 15:17
Оценка:
Здравствуйте, samius, Вы писали:

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

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

А я тебе показал, что не все дадено и показал что нужно дать еще.
Re[57]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 04.10.12 15:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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

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

I>А я тебе показал, что не все дадено и показал что нужно дать еще.

Ты не предъявил никаких убедительных рассуждений в пользу этой необходимости. Пример об умении водить и знании устройства автомобиля лишь подтвердил мои убеждения.
Когда я учил свою жену водить и она все время бросала сцепление, я думал что проблема в том, что она не понимает, зачем оно нужно и как работает. Пытался объяснить. К счастью, она научилась работать сцеплением так и не поняв, нафига. По ее разумению оно надо "что бы машина не дергалась". Сейчас она отлично водит на механике и на автомате, не понимая, в чем разница, кроме того что с автоматом не надо давить сцепление.
Примерно так же у нее и с екселем.
Re[19]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 07:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ты перестал пить палёную водку ? Самиус, а не я, говорит что для ФП достаточно вещей которые проходят в 4-5м классе.

Нет, все ходы записаны. Это вы интересовались, на основании чего Самиус рассчитывает на понимание концепции "функция" у его целевой аудитории.
А я вам пояснил, что эту концепцию дети начинают официально изучать в пятом классе, и ещё шесть лет учатся вещам, построенным на основе этой концепции.
I>А ты хотел что бы все вопросы обучения брались из книги Кнута ?
Нет, желательно брать вопросы обучения из книг по вопросам обучения, а не по вопросам "творческого мышления", написанным сотрудниками ФСБ.
Вот, например: http://books.google.com/books?id=HhIEAgUfGHwC&amp;printsec=frontcover


I>Вычислил правильно и времени хватило — значит умеет. Вычислил правильно, но времени потратил больше чем было — не умеет. Вычислил неправильно — не хватило. Берешь и смотришь решения задач из тех, кто ошибки в вычислениях, делаешь выводы.

Делаю выводы: у 100% первокурсников уже есть практика работы с подстановкой выражений. Некоторые умеют её лучше, некоторые хуже. Но практики работы с машиной Тьюринга нет ни у кого. Я не понимаю, почему этот очевидный для всех факт вам нужно объяснять столь многократно.

I>Когда школьник читает инструкцию, как заклеивать дыру в камере, то у него все хорошо с концепцией. А стоит ему заняться программированием, как вдруг оказывается, что та же концепция перестаёт работать.

Секрет в том, что это вовсе не та же концепция. В заклейке камеры не фигурируют переменные, instruction pointer, переходы и циклы.
I>На уроках русского языка мы писали всякие инструкции, заявлеия, отчеты, давали советы и тд и тд, и вдруг, ан уроке программирования все эти умения улетучиваются просто потому что это вдруг программирование.
"эти" — это какие? Умение правильно писать заявление никакого отношения к программированию не имеет. Ни к функциональному, ни к императивному.

I>Вобщем покажи хороший аналог подхода для обучения, http://worrydream.com/LearnableProgramming/, но что бы никакой императивщины.

Радует ваша способность приводить ссылки. Осталось ещё научиться читать тексты там. Вот вам цитата ровно оттуда:

Every programming language is made of metaphors, but some fit the mind better than others. Standard imperative programming uses the metaphor of "assigning to variables", shuffling bits between little boxes. Unlike the Logo turtle, this metaphor was not designed to resonate with how people learn and understand; it simply evolved as a thin layer over the metaphors used in the underlying machine architecture, such as "storing to memory".


I>У тебя какие то не те программисты. Товарищ, студент 5го курса, родил за день примерно три императивные версии.

Не, ну одну функциональную я и сейчас рожу за пять минут — верну (0, 0) для каждого узла. С учётом того, что вы забыли оговорить хоть какие-то требования, это решение удовлетворяет постановке.
А если вас интересуют алгоритмы планаризации графов с учётом эстетики результатов, то придётся долго читать нудные работы вроде Кандинского, ДеФроссю и прочее.

I>Это не опровержение, а указание на свойства экселя. Теоретически в ём можно всё. А на практике тебе может не хватить строчек или ячеек.


Ну, то есть к вычислительной модели Экселя претензий нет, только к количеству ячеек? Ок, понятно.
Я-то думал вы мне сейчас про отсутствие ФВП будете объяснять.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.10.12 08:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Для сравнения. Более менее адекватную модель вычислителя придется освоить, иначе программирования не получится.

G>>Бета-редукция более чем адекватна. Я не пойму чем она тебя не устраивает.
I>Она меня всем устраивает. Но глядя в решения задач я вижу, что люди толком не могут подстановку использовать, т.к. большая часть ошибок в вычислениях это именно подстановка.
Ту думаешь с МТ будет меньше ошибок?

I>>>Эти абстракции нужно выращивать,а не спускать сверху. Попробуй применить свой пример ан практике, например — дать матан в 3м классе. Ну, раз есть смысла обучать на высокоуровневых абстракциях, все должно прокатить на раз.

G>>Доказательство во по аналогии снова не прокатило. Матан опирается на арифметику, лямбда-исчисление не опирается на машину тьюринга.
I>Вообще говоря "арифметику" можно вывести из теории категорий по моему. Значит что бы не давать арифметику, даем сразу терию категорий.
Нельзя.

I>Пример попроще — вместо того, что бы решать задачи на объём и площадь, лучше взять да изучить сразу интеграл — резко появится отличный инструмент для решения задач на объем и площадь.

Так это ты пытаешься брать интегралы (обучать с помощью МТ) вместо использования простых средств (подстановка).



G>>Кстати в большинстве учебных заведений начинают с блок-схем. Они также не зависят ни от машин тьюрига, ни от лямбда-исчисления.

I>Честно — мне такие учебные заведения не известны. Начинают или с Си, или с Паскаля, или с Питона, или со Схемы, или с ассемблера. Других вещей не встречал.
У тебя в школе информатики не было?

I>>>Иллюстрация. Все осваивается начиная с "пощупать" + "посмотреть". Вообще всё. Исключения — способности вложеные в тебя в виде кое какие безусловных рефлексов.

G>>Иллюстрация вообще не в тему. Мыслительные процессы работают не так как тактильные.
I>Конечно не так, зато любая деятельность осваивается через сенсомоторную стадию. то есть "пощупать" и "посмотреть".
I>Повторю — любая. За доказательствами смотри в сторону когнитивной психологии.
Ты так и не объяснил что значит "пощупать" и "посмотреть" для программирования. Разве недостаточно набрать пару строк в интерпретаторе? Зачем изучать МТ?
Аналогично для автомобилей — чтобы попробовать ездить не надо изучать устройство автомобиля.


I>>>Первая проблема — дать пригодную модель вычислителя . Дальше её нужно будет улучшать, что бы она справлялась с более сложными задачами.

G>>Именно: бета-редукция -> вычисление с окружениями -> регистровая машина\стековая машина.

I>Не вычисление с окружениями, а особенности конкретного вычислителя, время, ресурсы, состояние и тд и тд.

Ты о чем? Вычисление с окружениями натягивается на любую реальную систему. Как раз изучение конкретного вычислителя не нужно для этого.

I>Вот здесь хорошая иллюстрация : http://worrydream.com/LearnableProgramming/

Обсуждение ты уже видел:
http://lionet.livejournal.com/119834.html?thread=3803674#t3803674

I>>>Задача 1 + пощупать + посмотреть -> концепция 1, задача 2 + пощупать + посмотреть-> концепция 2, задача N + пощупать + посмотреть -> концепция N

G>>Насчет "пощупать и посмотреть" — непонятно что это означает в плане мыслительного процесса.
I>Это значит, что ты сначала трогаешь нечто пальцем, смотришь на реакцию и делаешь вывод. Снова трогаешь, снова смотришь, снова делаешь вывод.
Ок, открываем интерпретатор и тыкаем, зачем тут МТ? Подстановочной модели более чем достаточно.

G>>>>ВМ опирается на школьный курс, лямбда исчисление не опирается на машину тьюринга. Подумай над этим.

I>>>возьми эксель и запрограммируй в ём какой нибудь энергетический алгоритм размещения графа.
G>>Это тут к чему? Пытаешься перевести тему?
I>Это тоже самое. Запрограммируй, а потом посмотрим, что да как.
Ну не сливайся ты так. Мы вообще-то об обучении говорим, а не о конкретных алгоритмах.
Re[15]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.10.12 08:16
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Верю. А за какое время студенты смогут освоить все это до уровня свободного владения ?

G>>Если голый рассказ дополнить практикой в том же объеме, то достаточно. По универским метрикам — 5 теоретических и 5 практических занятий будет достаточно.

I>Не достаточно

Ты можешь это конкретно обосновать? У тебя есть опыт? Думаю нет, тогда зачем такие заявления пишешь?

I>Есть фаза осмысления, которую отменить никак нельзя. В зависимости от степени новизны и индивидуальных особенностей, она будет от минут до дней и даже недель.

Ты о чем? По тем же университетским меркам 5 занятий это будет от 2 до 4 недель, времени на осмысление будет предостаточно.

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

Никто не заставляет за неделю такое изучать.

I>>>Объяснения не интересуют. Важно время на то, что бы попробовать все вещи руками, то есть, освоить вычислитель, что бы более менее адекватная моделька сложилась в голове.

G>>Как ты собрался МТ руками пробовать? Я не пойму о чем ты.
I>Необязательно непосредсвтенный контакт. Можно и опосредовано. Весь абстрактный опыт именно так и накапливается.
Вообще не понял о чем ты.
Открыть интерпретатор и набрать пару строк недостаточно? Что еще надо знать кроме базового синтаксиса и подстановочной модели?

G>>>>Да-да, я как раз об этом и говорю. Для того чтобы ездить мне все это не надо знать. Надо только понимать что двигатель соединен с колесами и как работает сцепление.

I>>>Ну то есть этого знать не надо, но только это и надо понимать. Опаньки !
G>>Нет, всего остального знать не надо, да и это необязательно.
I>Чем лучше ты хочешь осваивать автомобиль, тем более детальная нужна модель. Например потому, что многие вещи попробовать руками слишком трудно.
Да, но для начала его устройство знать совсем не надо. Для езды по городу\на дачу тоже. Это то чем занимается более 99,9% водителей. Для оставшихся менее 0.1% можно отдельное обучение.
В программировании к сожалению не все так просто, необходимость глубокого вникания в процессы нужно гораздо большему проценту людей. Но на стадии начального обучения совсем необязательно.

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

G>>>>Совершенно необязательно. У меня куча контр-примеров. Люди много лет ездят и не знают что такое подшипник.
I>>>Термина вполне возможно и не знают.
G>>Конструкции и подавно
I>Главное что бы модель была внятная, иначе ты даже задачу механику внятно не сможешь поставить
Задача механику: "стучит справа когда руль поворачиваю". Для этого не надо знать что попала грязь в подшипник шарнирного механизма.

I>>>Ты вероятно думаешь, будто я утверждаю, что надо знать устройство не хуже автомеханика или вообще конструктора ?

G>>Я слабо понимаю что ты утверждаешь, но я утверждаю что для вождения современного автомобиля вообще не надо знать его устройство.

I>Устройство == модель с определенной степенью детализации. Для начала хватит и так — есть колеса, значит это может ехать, есть руль, значит это может поворачивать. Но только для начала.

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

В программировании часто так и происходит. Напомню тебе что многие .NET программисты считают что value-type это те, которые размещаются на стеке. Это как раз эффект от излишней детализации в начале обучения.
Re[21]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 08:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

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

G> Ту думаешь с МТ будет меньше ошибок?

А ты перестал пить палёную водку ?

I>>Вообще говоря "арифметику" можно вывести из теории категорий по моему. Значит что бы не давать арифметику, даем сразу терию категорий.

G>Нельзя.

Это как же, лучше начинать с абстракций, но с абстракций нельзя ?

I>>Пример попроще — вместо того, что бы решать задачи на объём и площадь, лучше взять да изучить сразу интеграл — резко появится отличный инструмент для решения задач на объем и площадь.

G>Так это ты пытаешься брать интегралы (обучать с помощью МТ) вместо использования простых средств (подстановка).

Ты же хочешь сразу с абстракций начинать. Почему тогда сразу не с интегралов ?

I>>Честно — мне такие учебные заведения не известны. Начинают или с Си, или с Паскаля, или с Питона, или со Схемы, или с ассемблера. Других вещей не встречал.

G>У тебя в школе информатики не было?

Паскаль только на русском языке.

G>Ты так и не объяснил что значит "пощупать" и "посмотреть" для программирования. Разве недостаточно набрать пару строк в интерпретаторе? Зачем изучать МТ?


См ссылку от курилки.

G>Аналогично для автомобилей — чтобы попробовать ездить не надо изучать устройство автомобиля.


Не надо, это если ты пассажир автобуса.

I>>Вот здесь хорошая иллюстрация : http://worrydream.com/LearnableProgramming/

G>Обсуждение ты уже видел:
G>http://lionet.livejournal.com/119834.html?thread=3803674#t3803674

Там нет обсуждения, в одном из коментов откровенная чушь.

I>>Это значит, что ты сначала трогаешь нечто пальцем, смотришь на реакцию и делаешь вывод. Снова трогаешь, снова смотришь, снова делаешь вывод.

G>Ок, открываем интерпретатор и тыкаем, зачем тут МТ? Подстановочной модели более чем достаточно.

Для hello world не нужна детальная модель.

I>>Это тоже самое. Запрограммируй, а потом посмотрим, что да как.

G>Ну не сливайся ты так. Мы вообще-то об обучении говорим, а не о конкретных алгоритмах.

Обучение чему ? Вычисления простецких формул или же полноценном программированию, как дисциплине для инженеров ?
Re[16]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 09:06
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Не достаточно

G>Ты можешь это конкретно обосновать? У тебя есть опыт? Думаю нет, тогда зачем такие заявления пишешь?

Есть и опыт и кое какая подготовка. Мне интересно, как ты ты свои цифры вычислил, ибо ни в одном вузе нет и близко подобных вещей.

I>>Есть фаза осмысления, которую отменить никак нельзя. В зависимости от степени новизны и индивидуальных особенностей, она будет от минут до дней и даже недель.

G>Ты о чем? По тем же университетским меркам 5 занятий это будет от 2 до 4 недель, времени на осмысление будет предостаточно.

5 часов и 5 часов практики ? Не смеши. В любом нормальном вузе практики минимум вдвое больше чем теории. В хороших — в четверо. А вот в вузах бывшего СССР идет тенденция к уменьшению практики чуть не до нуля.

I>>Необязательно непосредсвтенный контакт. Можно и опосредовано. Весь абстрактный опыт именно так и накапливается.

G>Вообще не понял о чем ты.
G>Открыть интерпретатор и набрать пару строк недостаточно? Что еще надо знать кроме базового синтаксиса и подстановочной модели?

Смотри ссылку от курилки. Узучение модели вычислителя это как раз оно и есть.

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

G>Да, но для начала его устройство знать совсем не надо. Для езды по городу\на дачу тоже. Это то чем занимается более 99,9% водителей. Для оставшихся менее 0.1% можно отдельное обучение.

Я в курсе. Устройство = более менее адекватная модель. И это ни разу не знания на уровне автомеханика.

Эта фраза понятна или ты продолжаешь считать, что я требую знаний не хуже чем у механика или конструктора ?
Re[22]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.10.12 09:11
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


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

G>> Ту думаешь с МТ будет меньше ошибок?
I>А ты перестал пить палёную водку ?
Опять сливаешь? Ты же сам начал про ошибки

I>>>Вообще говоря "арифметику" можно вывести из теории категорий по моему. Значит что бы не давать арифметику, даем сразу терию категорий.

G>>Нельзя.
I>Это как же, лучше начинать с абстракций, но с абстракций нельзя ?
Нельзя вывести.

I>>>Пример попроще — вместо того, что бы решать задачи на объём и площадь, лучше взять да изучить сразу интеграл — резко появится отличный инструмент для решения задач на объем и площадь.

G>>Так это ты пытаешься брать интегралы (обучать с помощью МТ) вместо использования простых средств (подстановка).
I>Ты же хочешь сразу с абстракций начинать. Почему тогда сразу не с интегралов ?
Абстракции разные бывают. Я как раз говорил о наиболее простой абстракции (подстановка), ты говорил о сложной (МТ). То есть как раз ты предлагаешь интеграл вместо произведения ширины на высоту.


G>>Аналогично для автомобилей — чтобы попробовать ездить не надо изучать устройство автомобиля.

I>Не надо, это если ты пассажир автобуса.
И водителю не надо. Ты обратного даже показать не можешь, не то что доказать.

I>>>Вот здесь хорошая иллюстрация : http://worrydream.com/LearnableProgramming/

G>>Обсуждение ты уже видел:
G>>http://lionet.livejournal.com/119834.html?thread=3803674#t3803674
I>Там нет обсуждения, в одном из коментов откровенная чушь.
Там говорит человек, который имеет реальный опыт обучения. Чушь тут несешь только ты.

I>>>Это значит, что ты сначала трогаешь нечто пальцем, смотришь на реакцию и делаешь вывод. Снова трогаешь, снова смотришь, снова делаешь вывод.

G>>Ок, открываем интерпретатор и тыкаем, зачем тут МТ? Подстановочной модели более чем достаточно.
I>Для hello world не нужна детальная модель.
Много для чего не нужна детальная модель. Например для алгоритма хаффмана достаточно подстановки. А некоторые языки по семантике достаточно близки к подстановке и очень далеки от МТ.
Так что нету никакого смысла начинать с низкоуровневых абстракций.

I>>>Это тоже самое. Запрограммируй, а потом посмотрим, что да как.

G>>Ну не сливайся ты так. Мы вообще-то об обучении говорим, а не о конкретных алгоритмах.
I>Обучение чему ? Вычисления простецких формул или же полноценном программированию, как дисциплине для инженеров ?
Ты наверное забыл что большую часть программ можно сделать используя последовательности и комбинаторы. Для них достаточно подстановочной модели.
А также смотри ремарку про разные языки выше.
Re[20]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 09:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Ikemefula, Вы писали:


I>>Ты перестал пить палёную водку ? Самиус, а не я, говорит что для ФП достаточно вещей которые проходят в 4-5м классе.

S>Нет, все ходы записаны. Это вы интересовались, на основании чего Самиус рассчитывает на понимание концепции "функция" у его целевой аудитории.
S>А я вам пояснил, что эту концепцию дети начинают официально изучать в пятом классе, и ещё шесть лет учатся вещам, построенным на основе этой концепции.

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

I>>А ты хотел что бы все вопросы обучения брались из книги Кнута ?

S>Нет, желательно брать вопросы обучения из книг по вопросам обучения, а не по вопросам "творческого мышления", написанным сотрудниками ФСБ.
S>Вот, например: http://books.google.com/books?id=HhIEAgUfGHwC&amp;printsec=frontcover

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

I>>Вычислил правильно и времени хватило — значит умеет. Вычислил правильно, но времени потратил больше чем было — не умеет. Вычислил неправильно — не хватило. Берешь и смотришь решения задач из тех, кто ошибки в вычислениях, делаешь выводы.

S>Делаю выводы: у 100% первокурсников уже есть практика работы с подстановкой выражений. Некоторые умеют её лучше, некоторые хуже. Но практики работы с машиной Тьюринга нет ни у кого. Я не понимаю, почему этот очевидный для всех факт вам нужно объяснять столь многократно.

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

I>>Когда школьник читает инструкцию, как заклеивать дыру в камере, то у него все хорошо с концепцией. А стоит ему заняться программированием, как вдруг оказывается, что та же концепция перестаёт работать.

S>Секрет в том, что это вовсе не та же концепция. В заклейке камеры не фигурируют переменные, instruction pointer, переходы и циклы.

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

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

S>"эти" — это какие? Умение правильно писать заявление никакого отношения к программированию не имеет. Ни к функциональному, ни к императивному.

Это определенные умственные навыки которые непосредтсвенно используются и при программировании, и при написании заявлений и тд и тд.

S>

S>Every programming language is made of metaphors, but some fit the mind better than others. Standard imperative programming uses the metaphor of "assigning to variables", shuffling bits between little boxes. Unlike the Logo turtle, this metaphor was not designed to resonate with how people learn and understand; it simply evolved as a thin layer over the metaphors used in the underlying machine architecture, such as "storing to memory".


Конкретно эта часть в этой статье мне не нравится. Машина тьюринга это объект с которым люди сталкиваются именно при программировании. Но это вовсе не значит, что вся императивщина сводится именно к машине тьюринга.

I>>У тебя какие то не те программисты. Товарищ, студент 5го курса, родил за день примерно три императивные версии.

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

Это годная отмазка.
Re[58]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 09:40
Оценка:
Здравствуйте, samius, Вы писали:

I>>А я тебе показал, что не все дадено и показал что нужно дать еще.

S>Ты не предъявил никаких убедительных рассуждений в пользу этой необходимости. Пример об умении водить и знании устройства автомобиля лишь подтвердил мои убеждения.
S>Когда я учил свою жену водить и она все время бросала сцепление, я думал что проблема в том, что она не понимает, зачем оно нужно и как работает. Пытался объяснить. К счастью, она научилась работать сцеплением так и не поняв, нафига. По ее разумению оно надо "что бы машина не дергалась".

Вполне приемлемая модель устройства авто. Если она скажем захочет разгоняться как можно быстрее, ей придется освоить более адекватную модель, нежели "сцепление для того что бы машина не дергалась".
Re[21]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 09:46
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Это скорее всего просто научпоп и потому никакого света на процесс обучения не проливает, а просто распространяет чьи то модельки.

[facepalm]
I>Наверное потому, что я сам говорю ровно тоже — студенты учится не императивщине, а осваивают вычислитель, а уже потом переходят к освоению абстрации — машине тьюринга.
В том-то и дело, что нужно осваивать вычислитель, который сложнее машины Тьюринга.

I>Есть даже игры в детском саду, где надо бросать кубик и делать определенные действия. "Если у вас есть то и то, то пропустите ход, а если нет, то ходите вперед как показал кубик" Концепция вобщем та же, а вот переменных нет.

Концепция совершенно другая. Вам уже пять раз в этом топике указали на то, что императивное программирование не бывает без переменных и instruction pointer. А вы продолжаете долбить чушь, принимая декларативные утверждения типа "табуретка состоит из сиденья и ножек" за императивную программу по сборке табуретки.

I>Всего то мышление направлено на новый объект. Вот этот объект и надо исследовать. Т.е. пока что не машина тьюринга, а конкретный вычислитель.

I>Машина тьюринга это абстракция, её можно давать уже после того, как студент оформить целую кучку задач в конкретном вычислители.
Если у вас стоит задача научить программировать, то машину тьюринга можно вообще не давать, как и конкретного вычислителя.

I>Конкретно эта часть в этой статье мне не нравится. Машина тьюринга это объект с которым люди сталкиваются именно при программировании. Но это вовсе не значит, что вся императивщина сводится именно к машине тьюринга.

Рекомендую вам вернуться к истокам и освоить, что такое императивное программирование и чем оно отличается от функционального. Спойлер: это ровно Тьюринг против Чёрча. А уж какая именно машина в императиве — Поста, Тьюринга, Форт, x86 или Java VM — несущественные подробности. Существенно именно это — наличие изменяемого состояния. Причём в классическом императиве это состояние ещё и невидимо. Прочитайте статью, на которую вы ссылаетесь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 05.10.12 09:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Не достаточно

G>>Ты можешь это конкретно обосновать? У тебя есть опыт? Думаю нет, тогда зачем такие заявления пишешь?

I>Есть и опыт и кое какая подготовка. Мне интересно, как ты ты свои цифры вычислил, ибо ни в одном вузе нет и близко подобных вещей.


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

I>>>Есть фаза осмысления, которую отменить никак нельзя. В зависимости от степени новизны и индивидуальных особенностей, она будет от минут до дней и даже недель.

G>>Ты о чем? По тем же университетским меркам 5 занятий это будет от 2 до 4 недель, времени на осмысление будет предостаточно.

I>5 часов и 5 часов практики ? Не смеши. В любом нормальном вузе практики минимум вдвое больше чем теории. В хороших — в четверо. А вот в вузах бывшего СССР идет тенденция к уменьшению практики чуть не до нуля.

На первых курсах было поровну. На последних практики было больше. Имхо вполне нормальная картина.

I>>>Необязательно непосредсвтенный контакт. Можно и опосредовано. Весь абстрактный опыт именно так и накапливается.

G>>Вообще не понял о чем ты.
G>>Открыть интерпретатор и набрать пару строк недостаточно? Что еще надо знать кроме базового синтаксиса и подстановочной модели?
I>Смотри ссылку от курилки. Узучение модели вычислителя это как раз оно и есть.
Модели вычисления бывают разные. Ты пока не смог доказать что использование более сложной модели хоть чем-то оправдано.

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

G>>Да, но для начала его устройство знать совсем не надо. Для езды по городу\на дачу тоже. Это то чем занимается более 99,9% водителей. Для оставшихся менее 0.1% можно отдельное обучение.
I>Я в курсе. Устройство = более менее адекватная модель. И это ни разу не знания на уровне автомеханика.
Что значит "более адекватная" ? Адекватная для чего? Для вождения она не нужна, значит неадекватная.

Ты просто повторяешь утверждения, не подкрепляя их хоть какими-то фактами. Причем все твои утверждения опровергаются банальным наблюдением за реальным миром.
В реальном мире почти все умеют делать подстановку значений в формулы и почти никто не понимает МТ. В реальном мире миллионы людей водят автомобили, абсолютно не понимая как они устроены.
Re[23]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 10:00
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>> Ту думаешь с МТ будет меньше ошибок?

I>>А ты перестал пить палёную водку ?
G>Опять сливаешь? Ты же сам начал про ошибки

Разница исключительно в кривой вхождения. Так понятно ?

G>>>Нельзя.

I>>Это как же, лучше начинать с абстракций, но с абстракций нельзя ?
G>Нельзя вывести.

Можно.

I>>Ты же хочешь сразу с абстракций начинать. Почему тогда сразу не с интегралов ?

G>Абстракции разные бывают. Я как раз говорил о наиболее простой абстракции (подстановка), ты говорил о сложной (МТ). То есть как раз ты предлагаешь интеграл вместо произведения ширины на высоту.

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

G>>>Аналогично для автомобилей — чтобы попробовать ездить не надо изучать устройство автомобиля.

I>>Не надо, это если ты пассажир автобуса.
G>И водителю не надо. Ты обратного даже показать не можешь, не то что доказать.

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

G>Так что нету никакого смысла начинать с низкоуровневых абстракций.


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

I>>Обучение чему ? Вычисления простецких формул или же полноценном программированию, как дисциплине для инженеров ?

G>Ты наверное забыл что большую часть программ можно сделать используя последовательности и комбинаторы. Для них достаточно подстановочной модели.
G>А также смотри ремарку про разные языки выше.

Да, да, я в курсе.

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

Кроме того, в любой из задач нужно осваивать вычислитель. Это будет до тех пор, пока
1 вычисления требуют времени ресурсов
2 нужен специальный ввод-вывод
3 стоимость и время работы челвоека ненулевые

Вот можно будет избавиться от этого, тогда можно будет и забивать на вычислитель. Сейчас это можно для узкого круга задач, скажем посчитать сумму в Экселе

В сумме это все означает, чт надо осваивать вычислитель. Мозг умеет воспринимать информацию только чз органы чувств. Скажем, затраты ресурсов, времени, вычислительную сложность, ввод-вывод нужно сделать видимыми и осязаемыми, что бы можно было потрогать и посмотреть.
Re[58]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 10:13
Оценка:
Здравствуйте, samius, Вы писали:

S>Когда я учил свою жену водить и она все время бросала сцепление, я думал что проблема в том, что она не понимает, зачем оно нужно и как работает. Пытался объяснить. К счастью, она научилась работать сцеплением так и не поняв, нафига.


Если человек не понял, то это означает, что ты объяснял понятиями которые отсутствуют у этого человека.
То есть, ты толкал абстракции которые еще не прокачаны до нужного уровня а может и вовсе отсутствуют.
Других причин непонимания нет и быть не может.
То есть, нужно одно из двух
1 объяснения в терминах понятий которые уже есть
2 наглядный эксперимент, если нет нужных понятий или ты не знаешь про уровне подготовки.
Re[18]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 10:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Есть и опыт и кое какая подготовка. Мне интересно, как ты ты свои цифры вычислил, ибо ни в одном вузе нет и близко подобных вещей.


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


Не все.

I>>5 часов и 5 часов практики ? Не смеши. В любом нормальном вузе практики минимум вдвое больше чем теории. В хороших — в четверо. А вот в вузах бывшего СССР идет тенденция к уменьшению практики чуть не до нуля.

G>На первых курсах было поровну. На последних практики было больше. Имхо вполне нормальная картина.

Поровну == мало.

I>>Смотри ссылку от курилки. Узучение модели вычислителя это как раз оно и есть.

G>Модели вычисления бывают разные. Ты пока не смог доказать что использование более сложной модели хоть чем-то оправдано.

Я говорю про необходимость освоения вычислителя. Если у тебя есть вычислитель пригодный для решения актуальных задач на сей день, его тоже нужно изучать. "более сложная" модель нужн для "более сложных задач".
А совсем не надо знать модель когда ты вообще не программируешь.

водителей. Для оставшихся менее 0.1% можно отдельное обучение.
I>>Я в курсе. Устройство = более менее адекватная модель. И это ни разу не знания на уровне автомеханика.
G>Что значит "более адекватная" ? Адекватная для чего? Для вождения она не нужна, значит неадекватная.

Адекватная для конкретного применения. В данном случае — вождение.

G>Ты просто повторяешь утверждения, не подкрепляя их хоть какими-то фактами. Причем все твои утверждения опровергаются банальным наблюдением за реальным миром.


Опровергни хоть одно, только не голословно, а то у тебя кроме общих фраз не было.
Re[22]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 10:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Наверное потому, что я сам говорю ровно тоже — студенты учится не императивщине, а осваивают вычислитель, а уже потом переходят к освоению абстрации — машине тьюринга.

S>В том-то и дело, что нужно осваивать вычислитель, который сложнее машины Тьюринга.

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

S>Концепция совершенно другая. Вам уже пять раз в этом топике указали на то, что императивное программирование не бывает без переменных и instruction pointer. А вы продолжаете долбить чушь, принимая декларативные утверждения типа "табуретка состоит из сиденья и ножек" за императивную программу по сборке табуретки.


Скажу страшное — твой пример это ассертивное утверждение, а не императивное.

I>>Машина тьюринга это абстракция, её можно давать уже после того, как студент оформить целую кучку задач в конкретном вычислители.

S>Если у вас стоит задача научить программировать, то машину тьюринга можно вообще не давать, как и конкретного вычислителя.

Опаньки ! А эксель значит как конкретный вычислитель осваивать не надо ?

I>>Конкретно эта часть в этой статье мне не нравится. Машина тьюринга это объект с которым люди сталкиваются именно при программировании. Но это вовсе не значит, что вся императивщина сводится именно к машине тьюринга.

S>Рекомендую вам вернуться к истокам и освоить, что такое императивное программирование и чем оно отличается от функционального. Спойлер: это ровно Тьюринг против Чёрча. А уж какая именно машина в императиве — Поста, Тьюринга, Форт, x86 или Java VM — несущественные подробности. Существенно именно это — наличие изменяемого состояния. Причём в классическом императиве это состояние ещё и невидимо. Прочитайте статью, на которую вы ссылаетесь.

Изменяемому состоянию учить не надо, люди умеют работать с этим почти что искаропки. Например никто не ожидает обнаружить кофе в чашке, если этот кофе был только что выпит. Проблему вызывает только конкретный вычислитель и то по одной единственной причине — его нельзя непосредтсвенно ни пощупать, ни рассмотреть.
Re[23]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 10:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Скажу страшное — твой пример это ассертивное утверждение, а не императивное.

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

I>Опаньки ! А эксель значит как конкретный вычислитель осваивать не надо ?

Миллионы бухгалтеров подтверждают: не надо.

В екселе всё считается "само", безо всякого вычислителя. В нём нет скрытого состояния, instruction pointer и циклов.
Если ты написал в ячейку C1 выражение =A1+B1, то она так и будет равна сумме ячеек A1 и B1, в каком порядке ни меняй их значения.
В императивной программе (ничего, что я объясняю очевидное?) так не получится.
Вот простой пример:
A1 = 1;
B1 = 2;
C1 = A1+B1; 
A1 = 2;
Assert(C1==A1+B1)// Ахтунг!

Где вы тут видите вычислитель?

I>Изменяемому состоянию учить не надо, люди умеют работать с этим почти что искаропки. Например никто не ожидает обнаружить кофе в чашке, если этот кофе был только что выпит. Проблему вызывает только конкретный вычислитель и то по одной единственной причине — его нельзя непосредтсвенно ни пощупать, ни рассмотреть.

Надо, надо учить изменяемому состоянию. Даже если состояние искусственно сделать наглядным, то смысл программы уловить крайне сложно. То, что сейчас чашка пуста — неважно. Чтобы предсказать заранее, не перельётся ли кофе, нужно смотреть не на чашку, а на код, который был выполнен перед тем, как инструкция "налить кофе" пойдёт на выполнение. Вот вся эта концепция полностью отсутствует в мозгу неподготовленного человека.
А реальная программа — это множество разных "чашек с кофе".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[59]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 11:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Если человек не понял, то это означает, что ты объяснял понятиями которые отсутствуют у этого человека.

I>То есть, ты толкал абстракции которые еще не прокачаны до нужного уровня а может и вовсе отсутствуют.
I>Других причин непонимания нет и быть не может.
I>То есть, нужно одно из двух
I>1 объяснения в терминах понятий которые уже есть
I>2 наглядный эксперимент, если нет нужных понятий или ты не знаешь про уровне подготовки.

А нафига, если лучше человек водить не станет? Разбирать сцепление ей точно не придется.
Re[19]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 11:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Опровергни хоть одно, только не голословно, а то у тебя кроме общих фраз не было.
А чего тут опровергать? 99.5% современных водителей понятия не имеют о том, как работает двигатель, трансмиссия и рулевое управление в их машине. Вообще никакого понятия.
Кроме, разве что, наблюдаемых эффектов на уровне "давим газ — едем быстрее, давим тормоз — медленнее; поворачиваем руль влево — машина едет влево, поворачиваем вправо — машина едет вправо". Даже не пробуйте объявить эти знания "поверхностным знанием устройства автомобиля". Либо эти "знания" — заблуждение, либо человек честно понимает, что их у него нет.
И это никак не мешает этим людям прекрасно водить машину.

Точно так же бухгалтера не имеют ни малейшего представления о том, как устроен "вычислитель" в Excel. И это им никак не мешает успешно строить крайне сложные модели.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 11:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Императивное это будет так — "ножки прикреплены к сиденью".

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

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

На этом я всё же заканчиваю, потому как никакой объём слов, похоже, не способен заполнить пропасть в вашей голове.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[60]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 11:50
Оценка:
Здравствуйте, samius, Вы писали:

I>>То есть, ты толкал абстракции которые еще не прокачаны до нужного уровня а может и вовсе отсутствуют.

I>>Других причин непонимания нет и быть не может.
I>>То есть, нужно одно из двух
I>>1 объяснения в терминах понятий которые уже есть
I>>2 наглядный эксперимент, если нет нужных понятий или ты не знаешь про уровне подготовки.

S>А нафига, если лучше человек водить не станет? Разбирать сцепление ей точно не придется.


Нафига это другой вопрос и я не говорю про "разбирать сцепление".
Дергаться и наблюдать как двиг глохнет — это вобщем тоже наглядный эксперимент. Только неэффективный. Собственно примерно это и было в случае с твоей женой.
А вот если жена вдруг захочет разгоняться быстрее, ей придется узнать про сцепление побольше. Тут снова два варианта — объяснить или эксперимент.
Re[61]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 12:00
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>А нафига, если лучше человек водить не станет? Разбирать сцепление ей точно не придется.


I>Нафига это другой вопрос и я не говорю про "разбирать сцепление".

I>Дергаться и наблюдать как двиг глохнет — это вобщем тоже наглядный эксперимент. Только неэффективный. Собственно примерно это и было в случае с твоей женой.
Достаточно эффективный.
I>А вот если жена вдруг захочет разгоняться быстрее, ей придется узнать про сцепление побольше. Тут снова два варианта — объяснить или эксперимент.
И что нужно знать про сцепление что бы разгоняться быстрее? Я аж сам заинтригован. То что когда пахнет — это плохо?
Re[60]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 12:11
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Если человек не понял, то это означает, что ты объяснял понятиями которые отсутствуют у этого человека.

S>Если человек решает свои задачи, значит ему эти понятия вообще не нужны.

"Эти" это какие ?

Берём шесть человек которые отличаются подготовкой
1. прочитал про сцепление в словаре
2. увидел как используют сцепление
3. научился пользоваться сам
4. ремонтирует сцепление
5. конструирует сцепление
6. продает запчасти для сцепления

Вопрос — понимают ли эти люди одно и тоже когда слышат слово "сцепление" в разговоре на автомобильную тематику ?

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

S>Для чего вы хотите научить жену Самиуса устройству сцепления? Она прекрасно ездит и без ваших подробных (и, кстати, неверных) объяснений того, как работает её машина.


Я объяснил почему она не поняла его объяснений. Вы оба похоже вообще не понимаете что такое "понятие", откуда оно берется и как формируется.
Re[26]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 12:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Ты почему то притягиваешь сюда мутный термин "декларативный", что совершенно неуместно. Скажем если у функции GetContext убрать первые три буквы, то код получится более декларативным, но это вобщем не делает код менее императивным.
Не смешите меня. Прочитайте статью про learnable programming внимательно — там есть ехидные комментарии относительно именования функций.
Чтобы код стал более декларативным, нужно убирать совсем другие буквы. Нужно убирать изменение состояния.
А судя по названию функции, мы говорим как раз об изменяемом состоянии в полный рост. Как бы вы не заменяли глаголы существительными, декларативности не прибавится. Чтобы она прибавилась, нужно убавить императивность.

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

I>А переменные это специфика конкретного вычислителя, например машины тьюринга. Если под вычислителем будет выступать сам человек, то ему не надо никаких переменных вводить, ибо работать с изменяемым состоянием он умеет почти что "искаропки".
Ну так задача обучения программированию — это вовсе не обучение сборке мебели.
Для обучения императивному программированию и приходится работать с переменными и вычислителем.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[61]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 05.10.12 12:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Если, скажем, понятие "cцепление" отсутствует начисто, то учить вождению придется используя другие понятия вроде "жми вот эту педаль, отпускай плавно, что бы машина тронулась, не дергалась и не глохла".

Нет. Если в наличии коробка-автомат, то про существование сцепления можно вообще забыть, без потери каких-либо водительских навыков.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 12:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Скажу страшное — твой пример это ассертивное утверждение, а не императивное.

S>Прекрасно, прекрасно. Ну так и настольные игры не обучают детей императивному программированию.

Конечно нет, она прокачивают императивное мышление, которое применимо в императивном программировании.

I>>Опаньки ! А эксель значит как конкретный вычислитель осваивать не надо ?

S>Миллионы бухгалтеров подтверждают: не надо.

Надо.

S>В екселе всё считается "само", безо всякого вычислителя. В нём нет скрытого состояния, instruction pointer и циклов.


Есть куча всяких особенностей — ссылки, циклические ссылки, типы данных, ошибки и тд. Мне в свое время нужно было все это объяснять, например чел ожидал что умножение на ноль =B1*0 даст обязательно 0, а выходило почему то #REF!
Сюда же можно добавить целую кучу вещей, например сортировка или кнопка навроде рефреш.

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

I>>Изменяемому состоянию учить не надо, люди умеют работать с этим почти что искаропки. Например никто не ожидает обнаружить кофе в чашке, если этот кофе был только что выпит. Проблему вызывает только конкретный вычислитель и то по одной единственной причине — его нельзя непосредтсвенно ни пощупать, ни рассмотреть.

S>Надо, надо учить изменяемому состоянию. Даже если состояние искусственно сделать наглядным, то смысл программы уловить крайне сложно. То, что сейчас чашка пуста — неважно. Чтобы предсказать заранее, не перельётся ли кофе, нужно смотреть не на чашку, а на код, который был выполнен перед тем, как инструкция "налить кофе" пойдёт на выполнение. Вот вся эта концепция полностью отсутствует в мозгу неподготовленного человека.

Ты про вычислитель говоришь, а не про "изменяемое состояние".
Re[61]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 12:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я объяснил почему она не поняла его объяснений. Вы оба похоже вообще не понимаете что такое "понятие", откуда оно берется и как формируется.

Я вижу ты один все понимаешь, но именно у тебя одного никто не понимает, как работает map и подстановка.
Re[62]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 12:38
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я объяснил почему она не поняла его объяснений. Вы оба похоже вообще не понимаете что такое "понятие", откуда оно берется и как формируется.

S>Я вижу ты один все понимаешь, но именно у тебя одного никто не понимает, как работает map и подстановка.

Как обычно в случае твоих домыслов, тут несколько утверждений и все ложные.
Во первых, не я один.
Во вторых, именно у меня map понимают, т.к. я знаю что именно нужно делать что бы это понимание возникло. Тот факт, что есть люди которые не понимают этот map или ФП, следует, например, из результатов собеседований (разные страны, в т.ч. Россия).
Re[63]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 12:42
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Я вижу ты один все понимаешь, но именно у тебя одного никто не понимает, как работает map и подстановка.


I>Как обычно в случае твоих домыслов, тут несколько утверждений и все ложные.

I>Во первых, не я один.
I>Во вторых, именно у меня map понимают, т.к. я знаю что именно нужно делать что бы это понимание возникло.
Ну дак а чего ты тут мутишь воду который месяц?
I>Тот факт, что есть люди которые не понимают этот map или ФП, следует, например, из результатов собеседований (разные страны, в т.ч. Россия).
А ты не думал что эти люди его не понимают просто от того что не интересовались ФП и что им никто этот map объяснить не пытался?

Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?
Re[62]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 12:43
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Если, скажем, понятие "cцепление" отсутствует начисто, то учить вождению придется используя другие понятия вроде "жми вот эту педаль, отпускай плавно, что бы машина тронулась, не дергалась и не глохла".

S>Нет. Если в наличии коробка-автомат, то про существование сцепления можно вообще забыть, без потери каких-либо водительских навыков.

Я однажды видел как два клоуна пытались с толкача завести авто с гидротрансформатором, и еще пару случаев, как такие же клоуны не могли выбраться из ямы с тем же гидротрансформатором.
Забыть например про гидротрансформатор не получится, в силу определенных его особенностей. Например потеря тяги из за особенностей использования масла и тд и тд и тд.
Re[27]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 13:03
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Чтобы код стал более декларативным, нужно убирать совсем другие буквы. Нужно убирать изменение состояния.

S>А судя по названию функции, мы говорим как раз об изменяемом состоянии в полный рост. Как бы вы не заменяли глаголы существительными, декларативности не прибавится. Чтобы она прибавилась, нужно убавить императивность.

object initializer, collection initializer подходит под это или нет ? А то везде пишут что эт делает код более декларативным

I>>А переменные это специфика конкретного вычислителя, например машины тьюринга. Если под вычислителем будет выступать сам человек, то ему не надо никаких переменных вводить, ибо работать с изменяемым состоянием он умеет почти что "искаропки".

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

Я и говорю — основная проблема здесь это вычислитель. И так везде, даже в Экселе.
Re[64]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 13:08
Оценка:
Здравствуйте, samius, Вы писали:

I>>Тот факт, что есть люди которые не понимают этот map или ФП, следует, например, из результатов собеседований (разные страны, в т.ч. Россия).

S>А ты не думал что эти люди его не понимают просто от того что не интересовались ФП и что им никто этот map объяснить не пытался?

Я, в отличие от тебя, задаю прямые вопросы. Популярный ответ — "пробовал ФП, не знаю где применить" и "ну мне for понятнее". Что интересно, на форумах RSDN ровно та же картина. Минимум раз месяц кто нибудь создает тред что бы сообщить, что ему for понятнее чем map.

S>Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?


Здесь снова несколько утверждений и все они или ложны или не имеют смысла.
Re[65]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 13:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Тот факт, что есть люди которые не понимают этот map или ФП, следует, например, из результатов собеседований (разные страны, в т.ч. Россия).

S>>А ты не думал что эти люди его не понимают просто от того что не интересовались ФП и что им никто этот map объяснить не пытался?

I>Я, в отличие от тебя, задаю прямые вопросы. Популярный ответ — "пробовал ФП, не знаю где применить" и "ну мне for понятнее". Что интересно, на форумах RSDN ровно та же картина. Минимум раз месяц кто нибудь создает тред что бы сообщить, что ему for понятнее чем map.

Ты задаешь прямые вопросы и делаешь негодные выводы из ответов. То что человек пробовал ФП, как он говорит, вовсе не значит что он над ним прочах столькоже, сколько над императивом и так и не смог применить.
Я те так же могу сказать, что пробовал играть на скрипке, херня получается. И что примечательно, убежден что на форумах RSDN ровно та же картина, хоть никто и треды не создает что бы это сообщить.

S>>Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?


I>Здесь снова несколько утверждений и все они или ложны или не имеют смысла.

Разуй глаза, там нет утверждений
Re[66]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.10.12 14:29
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я, в отличие от тебя, задаю прямые вопросы. Популярный ответ — "пробовал ФП, не знаю где применить" и "ну мне for понятнее". Что интересно, на форумах RSDN ровно та же картина. Минимум раз месяц кто нибудь создает тред что бы сообщить, что ему for понятнее чем map.

S>Ты задаешь прямые вопросы и делаешь негодные выводы из ответов.

Покажи пример "негодного вывода", раз уж он тебе известен.

>То что человек пробовал ФП, как он говорит, вовсе не значит что он над ним прочах столькоже, сколько над императивом и так и не смог применить.


И снова от тебя какие то домыслы

S>>>Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?


I>>Здесь снова несколько утверждений и все они или ложны или не имеют смысла.

S>Разуй глаза, там нет утверждений

"высказываний". Но не важно, там все равно домыслы, которые не имеет ко мне никакого отношения.
Re[67]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 05.10.12 15:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Я, в отличие от тебя, задаю прямые вопросы. Популярный ответ — "пробовал ФП, не знаю где применить" и "ну мне for понятнее". Что интересно, на форумах RSDN ровно та же картина. Минимум раз месяц кто нибудь создает тред что бы сообщить, что ему for понятнее чем map.

S>>Ты задаешь прямые вопросы и делаешь негодные выводы из ответов.

I>Покажи пример "негодного вывода", раз уж он тебе известен.

Ну дак это твой пресловутый вывод о том что map тяжелее for-а.

>>То что человек пробовал ФП, как он говорит, вовсе не значит что он над ним прочах столькоже, сколько над императивом и так и не смог применить.


I>И снова от тебя какие то домыслы

Что я тут придумал? Что не следует из того что пробовал? Попробуй опровергни!

S>>>>Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?


I>>>Здесь снова несколько утверждений и все они или ложны или не имеют смысла.

S>>Разуй глаза, там нет утверждений

I>"высказываний". Но не важно, там все равно домыслы, которые не имеет ко мне никакого отношения.

Не имеют отношения — ответь "нет", чего ты елозишь как уж?
Я сознательно применил гиперболу. Я подозреваю что ты собеседуешь ДАЛЕКО не на позиции ФП разработчиков. Так почему же ты от них ожидаешь понимания ФП и map-а?
Для успешного применения ФП надо осваивать другую парадигму, а не "пробовать". Про скрипку я тебе не зря написал.
Re[28]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.10.12 05:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>object initializer, collection initializer подходит под это или нет ? А то везде пишут что эт делает код более декларативным

Слабо, но подходят. Подходят — потому, что они не сводятся к переименованию методов AddItem в Item. Слабо — потому, что это синтаксический сахар для совершенно определённого императивного кода. Сравните, например, с SQL, где left join вовсе не является синтаксическим сахаром для foreach.


I>Я и говорю — основная проблема здесь это вычислитель. И так везде, даже в Экселе.

Это опровергается наличием миллионов бухгалтеров, которые успешно пользуются екселем, ничего не зная про вычислитель.
Вам сейчас захочется опять начать фантазировать про то, что у них в голове есть "приемлемо подробная модель вычислителя" — не трудитесь.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[63]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 06.10.12 05:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я однажды видел как два клоуна пытались с толкача завести авто с гидротрансформатором, и еще пару случаев, как такие же клоуны не могли выбраться из ямы с тем же гидротрансформатором.

О да, этот одиночный пример конечно же опровергает успешный опыт миллионов других автолюбителей.

I>Забыть например про гидротрансформатор не получится, в силу определенных его особенностей. Например потеря тяги из за особенностей использования масла и тд и тд и тд.

Впервые об этом слышу. Вожу с 2001 года.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[64]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 08:15
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Я однажды видел как два клоуна пытались с толкача завести авто с гидротрансформатором, и еще пару случаев, как такие же клоуны не могли выбраться из ямы с тем же гидротрансформатором.

S>О да, этот одиночный пример конечно же опровергает успешный опыт миллионов других автолюбителей.

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

I>>Забыть например про гидротрансформатор не получится, в силу определенных его особенностей. Например потеря тяги из за особенностей использования масла и тд и тд и тд.

S>Впервые об этом слышу. Вожу с 2001 года.
S>

Возможно у тебя очень хороший автос и тебе не приходилось ни с чем сталкиваться
Re[29]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 08:18
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Я и говорю — основная проблема здесь это вычислитель. И так везде, даже в Экселе.

S>Это опровергается наличием миллионов бухгалтеров, которые успешно пользуются екселем, ничего не зная про вычислитель.
S>Вам сейчас захочется опять начать фантазировать про то, что у них в голове есть "приемлемо подробная модель вычислителя" — не трудитесь.

Из тех, с кем я сталкивался, люди хорошо понимают и ссылки, и циклические ссылки и разницу в типах данных и тд и тд и тд. И это, что характерно, ни разу не технари.
А ты утверждаешь, что бухгалтеры ничего такго не знают. Знают, еще как.
Re[68]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 08:31
Оценка:
Здравствуйте, samius, Вы писали:

I>>Покажи пример "негодного вывода", раз уж он тебе известен.

S>Ну дак это твой пресловутый вывод о том что map тяжелее for-а.

Сложнее, т.к. это абстракция более высокого уровня. И к собеседованиям это не имеет никакого отношения. Вобщем телепат из тебя никудышний.

I>>И снова от тебя какие то домыслы

S>Что я тут придумал? Что не следует из того что пробовал? Попробуй опровергни!

I>>"высказываний". Но не важно, там все равно домыслы, которые не имеет ко мне никакого отношения.

S>Не имеют отношения — ответь "нет", чего ты елозишь как уж?

Если хочешь, объясню на пальцах, что такое пресуппозиция и почему твое высказывание не может быть ни ложным ни истинным. Создавай новый топик.

S>Я сознательно применил гиперболу.


Ты просто передёргиваешь

>Я подозреваю что ты собеседуешь ДАЛЕКО не на позиции ФП разработчиков. Так почему же ты от них ожидаешь понимания ФП и map-а?


ФП разработчики, императивные разработчики — такое в своём уме никто никогда не требует. Есть конкретные цели, задачи, вот под них и ищутся люди. А что они умеют это уже другой вопрос. По моему опыту ФП хорошо идёт у людей с опытом от 5 лет и более. Практически все "функционалисты" которые хоть как то мне знакомы, в прошлом суровые С++ники.

S>Для успешного применения ФП надо осваивать другую парадигму, а не "пробовать". Про скрипку я тебе не зря написал.


Осваивать легко, а пробовать сложно ? Вот так чудеса !
Re[69]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.12 08:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Покажи пример "негодного вывода", раз уж он тебе известен.

S>>Ну дак это твой пресловутый вывод о том что map тяжелее for-а.

I>Сложнее, т.к. это абстракция более высокого уровня.


Абстракция более высокого уровня проще. Любой высокоуровневый ЯП проще ассемблера, C# проще C++.
Абстракция и нужна чтобы скрыть незначащие детали.

Если что я говорю о применении, а не об устройстве.

Так вот в применении for гораздо сложнее map
Re[30]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.10.12 09:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:
I>Из тех, с кем я сталкивался, люди хорошо понимают и ссылки, и циклические ссылки и разницу в типах данных и тд и тд и тд. И это, что характерно, ни разу не технари.
I>А ты утверждаешь, что бухгалтеры ничего такго не знают. Знают, еще как.
Нет, я такого не утверждаю. Я утверждаю, что бухгалтеры ничего не знают про императивное программирование.
Я в курсе про существование VBA, но в наблюдаемой реальности он занимает пренебрежимо малую долю.
Для императивного программирования нужно понимать и ссылки (и не так, как в екселе, где всё наглядно, а как в С++, где ссылка вводит синоним, кроме случаев её использования в роли члена класса, и т.п.), и типы данных, и ещё и концепции instruction pointer и переменных с различным расположением — глобальных, стековых, экземплярных.

Ну так зачем платить больше (с)?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[65]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.10.12 09:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Возможно у тебя очень хороший автос и тебе не приходилось ни с чем сталкиваться

Отлично, так и запишем: знания подробностей внутреннего устройства нужно для плохих реализаций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[69]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 09:24
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Ну дак это твой пресловутый вывод о том что map тяжелее for-а.


I>Сложнее, т.к. это абстракция более высокого уровня. И к собеседованиям это не имеет никакого отношения. Вобщем телепат из тебя никудышний.

Тут телепат не нужен, что бы понять о чем ты нудишь которую неделю, все время ссылаясь на свой опыт собеседований.

I>>>И снова от тебя какие то домыслы

S>>Что я тут придумал? Что не следует из того что пробовал? Попробуй опровергни!
даже пробовать не стал

I>>>"высказываний". Но не важно, там все равно домыслы, которые не имеет ко мне никакого отношения.

S>>Не имеют отношения — ответь "нет", чего ты елозишь как уж?

I>Если хочешь, объясню на пальцах, что такое пресуппозиция и почему твое высказывание не может быть ни ложным ни истинным. Создавай новый топик.

Тебе может объяснить на пальцах, что это был вопрос? Как ты вообще умудряешься применять "ложный или истинный" к вопросу?

S>>Я сознательно применил гиперболу.


I>Ты просто передёргиваешь

А ты недодергиваешь

>>Я подозреваю что ты собеседуешь ДАЛЕКО не на позиции ФП разработчиков. Так почему же ты от них ожидаешь понимания ФП и map-а?


I>ФП разработчики, императивные разработчики — такое в своём уме никто никогда не требует. Есть конкретные цели, задачи, вот под них и ищутся люди.

Ну смотри, одна вакансия C# WinForms, другая — Erlang. На первую не набегут "функционалисты", на вторую не набегут "императивщики", кроме разве что залетных, которые не знают ни того ни другого.

I>А что они умеют это уже другой вопрос. По моему опыту ФП хорошо идёт у людей с опытом от 5 лет и более. Практически все "функционалисты" которые хоть как то мне знакомы, в прошлом суровые С++ники.

Прально, ФП-ой интересуются в основном те, которым стало скучно в императиве. Если вакансий ФП будет хотя бы втрое меньше чем в ИП, то в изобилии появятся и те, кто с ФП начнет свою карьеру. А до тех пор твои наблюдения малого стоят.

S>>Для успешного применения ФП надо осваивать другую парадигму, а не "пробовать". Про скрипку я тебе не зря написал.


I>Осваивать легко, а пробовать сложно ? Вот так чудеса !

Никаких чудес. Пробовать ИП тоже не просто. Иначе бы все пробовали и шли пилить продакшн. И ты бы не ныл по поводу индустрии.
Re[70]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 10:29
Оценка:
Здравствуйте, samius, Вы писали:

I>>Если хочешь, объясню на пальцах, что такое пресуппозиция и почему твое высказывание не может быть ни ложным ни истинным. Создавай новый топик.

S>Тебе может объяснить на пальцах, что это был вопрос? Как ты вообще умудряешься применять "ложный или истинный" к вопросу?

Вопрос "да-нет" всегда содержит высказывание которое или истинно или ложно. Твой вопрос предполагает "да-нет", но высказывание в нем не может быть ни истинным, ни ложным.

I>>ФП разработчики, императивные разработчики — такое в своём уме никто никогда не требует. Есть конкретные цели, задачи, вот под них и ищутся люди.

S>Ну смотри, одна вакансия C# WinForms, другая — Erlang. На первую не набегут "функционалисты", на вторую не набегут "императивщики", кроме разве что залетных, которые не знают ни того ни другого.

А если так — "распределенные приложения + мобильные клиенты для них" ?

I>>А что они умеют это уже другой вопрос. По моему опыту ФП хорошо идёт у людей с опытом от 5 лет и более. Практически все "функционалисты" которые хоть как то мне знакомы, в прошлом суровые С++ники.

S>Прально, ФП-ой интересуются в основном те, которым стало скучно в императиве. Если вакансий ФП будет хотя бы втрое меньше чем в ИП, то в изобилии появятся и те, кто с ФП начнет свою карьеру. А до тех пор твои наблюдения малого стоят.

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

I>>Осваивать легко, а пробовать сложно ? Вот так чудеса !

S>Никаких чудес. Пробовать ИП тоже не просто. Иначе бы все пробовали и шли пилить продакшн. И ты бы не ныл по поводу индустрии.

Попробовать ИП очень просто. Практически все выпускники технических вузов успешно пробуют.
Re[71]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 10:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Вопрос "да-нет" всегда содержит высказывание которое или истинно или ложно. Твой вопрос предполагает "да-нет", но высказывание в нем не может быть ни истинным, ни ложным.

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

S>>Ну смотри, одна вакансия C# WinForms, другая — Erlang. На первую не набегут "функционалисты", на вторую не набегут "императивщики", кроме разве что залетных, которые не знают ни того ни другого.


I>А если так — "распределенные приложения + мобильные клиенты для них" ?

Без уточнения платформы на такие вакансии функциональщики не сбегутся, будь уверен.

S>>Прально, ФП-ой интересуются в основном те, которым стало скучно в императиве. Если вакансий ФП будет хотя бы втрое меньше чем в ИП, то в изобилии появятся и те, кто с ФП начнет свою карьеру. А до тех пор твои наблюдения малого стоят.


I>Скучно тебе стало, а ФП это просто очередной этап развития программиста, обычно следует непосредственно после императивного. Стимулом является не скука, как у тебя, а желание решать другие задачи. Собственно это самое желание было всегда, только задачи внезапно стали совсем другими.

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

S>>Никаких чудес. Пробовать ИП тоже не просто. Иначе бы все пробовали и шли пилить продакшн. И ты бы не ныл по поводу индустрии.


I>Попробовать ИП очень просто. Практически все выпускники технических вузов успешно пробуют.

Дай им такой же объем ФП и считай что они его тоже попробовали. В чем проблема?
Re[31]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 10:48
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Из тех, с кем я сталкивался, люди хорошо понимают и ссылки, и циклические ссылки и разницу в типах данных и тд и тд и тд. И это, что характерно, ни разу не технари.

I>>А ты утверждаешь, что бухгалтеры ничего такго не знают. Знают, еще как.
S>Нет, я такого не утверждаю. Я утверждаю, что бухгалтеры ничего не знают про императивное программирование.

Им и не надо знать императивщину. С экселем им надо понимать вычислительную модель предоставляемую экселем с её ограничениями, свойствами и тд. Она вобщем достаточно простая, но никуда от этого не деться.
Re[70]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 10:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Сложнее, т.к. это абстракция более высокого уровня.


G>Абстракция более высокого уровня проще.


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

G>Так вот в применении for гораздо сложнее map


Для кого сложнее ? Если человек только что сел за программирование, у него нет в голове такой абстракции, как map, а задачи скажем на обработку последовательностей он вообще не решал. for для него это одна из самых первых абстраций, когда он уже попробовал инструкции и ветвления.
Re[72]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 12:04
Оценка:
Здравствуйте, samius, Вы писали:

I>>Вопрос "да-нет" всегда содержит высказывание которое или истинно или ложно. Твой вопрос предполагает "да-нет", но высказывание в нем не может быть ни истинным, ни ложным.

S>Не вижу в нем ничего такого, что не позволяет ему быть истинным или ложным. Вопрос ровно такой же как и следующий: ты пьян?

Я так понял, ты чего то не видишь. Хочешь это обсудить или хочешь что бы я показал тебе то, чего ты не видишь ?

I>>Скучно тебе стало, а ФП это просто очередной этап развития программиста, обычно следует непосредственно после императивного. Стимулом является не скука, как у тебя, а желание решать другие задачи. Собственно это самое желание было всегда, только задачи внезапно стали совсем другими.

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

А я где то написал что задачи бывают императивными ? Особенности твоего зрения забавляют, продолжай

I>>Попробовать ИП очень просто. Практически все выпускники технических вузов успешно пробуют.

S>Дай им такой же объем ФП и считай что они его тоже попробовали. В чем проблема?

Теперь ты начинашь понимать, о чем я говорю уже две недели — о кривой вхождения.
Re[73]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 12:09
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Я так понял, ты чего то не видишь. Хочешь это обсудить или хочешь что бы я показал тебе то, чего ты не видишь ?

Я так понимаю, что отвечать на тот вопрос ты не хочешь настолько, что готов увести тему куда угодно.

I>>>Скучно тебе стало, а ФП это просто очередной этап развития программиста, обычно следует непосредственно после императивного. Стимулом является не скука, как у тебя, а желание решать другие задачи. Собственно это самое желание было всегда, только задачи внезапно стали совсем другими.

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

I>А я где то написал что задачи бывают императивными ? Особенности твоего зрения забавляют, продолжай

Ты написал о желании решать "другие задачи". Отсюда я и сделал вывод что ты делишь задачи. Если не так, то что за такие "другие задачи"?

I>Теперь ты начинашь понимать, о чем я говорю уже две недели — о кривой вхождения.

Нет, перестаю понимать. Ибо что ты знаешь о кривой вхождения в ФП, если у тебя такие проблемы с подстановкой в функции. Мне кажется что даже о кривой вхождения в школьный курс с тобой рано разговаривать.
Re[74]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 13:11
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я так понял, ты чего то не видишь. Хочешь это обсудить или хочешь что бы я показал тебе то, чего ты не видишь ?

S>Я так понимаю, что отвечать на тот вопрос ты не хочешь настолько, что готов увести тему куда угодно.

Кто ж виноват, что у тебя простые вопросы только навроде "Ты пьян ?"

I>>А я где то написал что задачи бывают императивными ? Особенности твоего зрения забавляют, продолжай

S>Ты написал о желании решать "другие задачи". Отсюда я и сделал вывод что ты делишь задачи. Если не так, то что за такие "другие задачи"?

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

I>>Теперь ты начинашь понимать, о чем я говорю уже две недели — о кривой вхождения.

S>Нет, перестаю понимать. Ибо что ты знаешь о кривой вхождения в ФП, если у тебя такие проблемы с подстановкой в функции. Мне кажется что даже о кривой вхождения в школьный курс с тобой рано разговаривать.

Обучить программированию очень легко — дал Эксел, увидел что все поняли, принял экзамен на следующий день и всё готово, вот она — простота фукнционального программирования.
Теперь см выше — решение задач в конкретной области. Например окажется, что надо обрабатывать изображения или звук. Пробуем делать это на Экселе и получаем отлуп.
Итого — программированию научили ? Да. Инженера подготовили — нет.
Re[75]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 13:36
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Я так понимаю, что отвечать на тот вопрос ты не хочешь настолько, что готов увести тему куда угодно.


I>Кто ж виноват, что у тебя простые вопросы только навроде "Ты пьян ?"

Он всяко понятнее чем твой излюбленный про "перестал пить водку по утрам".
Вобщем зачет по уходу от вопросов.

S>>Ты написал о желании решать "другие задачи". Отсюда я и сделал вывод что ты делишь задачи. Если не так, то что за такие "другие задачи"?


I>Делю, конечно же. Только не на императивные или функциональные. Мне лень повторять простые вещи, что цель(одна из) вуза это подготовка инженеров в конкретной области. То есть, выпускники обязаны уметь решать определенные задачи. То есть, область и определяет задачи.

Область определяет задачи, но не способы их решения. Так раскрой мне секрет, на какие такие другие задачи меня вдруг внезапно потянуло, в связи с чем я стал осваивать ФП?

I>Обучить программированию очень легко — дал Эксел, увидел что все поняли, принял экзамен на следующий день и всё готово, вот она — простота фукнционального программирования.

I>Теперь см выше — решение задач в конкретной области. Например окажется, что надо обрабатывать изображения или звук. Пробуем делать это на Экселе и получаем отлуп.
И тут внезапно оказывается что Эксел — это специализированный инструмент, а не язык общего назначения. Стоит взять специализированный инструмент для обработки звука/изображения и все впорядке.
I>Итого — программированию научили ? Да. Инженера подготовили — нет.
Подготовка инженера заключается восе не в том, что бы научить его решать конкретные задачи конкретным инструментом. Инженер должен уметь искать решения. Естественно, что обучение одному лишь специализированному языку в общем случае не будет достаточно для подготовки инженера. И никто тебе не предлагал заменить курс программирования Экселем. Тоже ведь передергиваешь.
Re[72]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 13:48
Оценка:
Здравствуйте, gandjustas, Вы писали:

I>>Ну, давай по кругу — давай сразу интеграл что бы задачи на площать считать. Раз абстракия проще,значит никаких проблем с освоением быть не должно. В каком классе начинают считать задачи на площать ?


G>Сумма для вычисления площади прямоугольника — абстракция над операцией интегрирования, скрывает ненужные детали.


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

I>>Для кого сложнее ? Если человек только что сел за программирование, у него нет в голове такой абстракции, как map, а задачи скажем на обработку последовательностей он вообще не решал. for для него это одна из самых первых абстраций, когда он уже попробовал инструкции и ветвления.


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


Надо, но их нет. Следоватеьлно, прежде чем давать map надо дать такие абстрации как "последовательность", "итерация".
Re[76]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 14:02
Оценка:
Здравствуйте, samius, Вы писали:

I>>Кто ж виноват, что у тебя простые вопросы только навроде "Ты пьян ?"

S>Он всяко понятнее чем твой излюбленный про "перестал пить водку по утрам".

Это прием аналогичный твоему вопросу, означает примерно следующее — если ты не пьешь и никогда не пил водку по утрам, то на него нельзя ответить ни "да", ни "нет".

S>Вобщем зачет по уходу от вопросов.


Разумеется, кто ж в своем уме будет на всякое непотребство отвечать ?

I>>Делю, конечно же. Только не на императивные или функциональные. Мне лень повторять простые вещи, что цель(одна из) вуза это подготовка инженеров в конкретной области. То есть, выпускники обязаны уметь решать определенные задачи. То есть, область и определяет задачи.

S>Область определяет задачи, но не способы их решения. Так раскрой мне секрет, на какие такие другие задачи меня вдруг внезапно потянуло, в связи с чем я стал осваивать ФП?

Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области. Обработка данных — императивщина. Управление ресурсами — императивщина. Ввод-вывод — императивщина.
Конкретно с тобой все просто — тебе стало скучно. Ты поработал в коллективе, решил что слишком крут для него, решил сидеть дома и "не работать с дураками", а что бы было куда девать энергию, поменял C# на С++ а потом на F#. Смысла в этом никакого — тебе всё равно будет скучно.

I>>Обучить программированию очень легко — дал Эксел, увидел что все поняли, принял экзамен на следующий день и всё готово, вот она — простота фукнционального программирования.

I>>Теперь см выше — решение задач в конкретной области. Например окажется, что надо обрабатывать изображения или звук. Пробуем делать это на Экселе и получаем отлуп.
S>И тут внезапно оказывается что Эксел — это специализированный инструмент, а не язык общего назначения. Стоит взять специализированный инструмент для обработки звука/изображения и все впорядке.

I>>Итого — программированию научили ? Да. Инженера подготовили — нет.

S>Подготовка инженера заключается восе не в том, что бы научить его решать конкретные задачи конкретным инструментом.

Вообще то я не говорил "конкретные задачи конкретным инструментом", а явно указал на область деятельности.

>Естественно, что обучение одному лишь специализированному языку в общем случае не будет достаточно для подготовки инженера. И никто тебе не предлагал заменить курс программирования Экселем.


Я показал пример, который показывает что наущение программированию может никак соответвовать задаче "подготовка инженера в конкретной области".
Re[77]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 14:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Это прием аналогичный твоему вопросу, означает примерно следующее — если ты не пьешь и никогда не пил водку по утрам, то на него нельзя ответить ни "да", ни "нет".

Тот мой вопрос не обладает такой фичей, или ты его не понял.

S>>Область определяет задачи, но не способы их решения. Так раскрой мне секрет, на какие такие другие задачи меня вдруг внезапно потянуло, в связи с чем я стал осваивать ФП?


I>Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области. Обработка данных — императивщина. Управление ресурсами — императивщина. Ввод-вывод — императивщина.

Чушь
I>Конкретно с тобой все просто — тебе стало скучно. Ты поработал в коллективе, решил что слишком крут для него, решил сидеть дома и "не работать с дураками", а что бы было куда девать энергию, поменял C# на С++ а потом на F#. Смысла в этом никакого — тебе всё равно будет скучно.
Гадалка из тебя хреновая — это раз. Два — ты сам сказал что меня потянуло на другие задачи, теперь увиливаешь от прямого ответа. Балаболка.

I>Вообще то я не говорил "конкретные задачи конкретным инструментом", а явно указал на область деятельности.

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

I>Я показал пример, который показывает что наущение программированию может никак соответвовать задаче "подготовка инженера в конкретной области".

>И никто тебе не предлагал заменить курс программирования Экселем.
Re[78]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 14:56
Оценка:
Здравствуйте, samius, Вы писали:

I>>Это прием аналогичный твоему вопросу, означает примерно следующее — если ты не пьешь и никогда не пил водку по утрам, то на него нельзя ответить ни "да", ни "нет".

S>Тот мой вопрос не обладает такой фичей, или ты его не понял.


"Я подозреваю что ты собеседуешь ДАЛЕКО не на позиции ФП разработчиков. Так почему же ты от них ожидаешь понимания ФП и map-а?"
"Не имеют отношения — ответь "нет", чего ты елозишь как уж? "

Здесь какое то утверждение на счет твоих подозрений. Потом не понятно откуда берется "почему ..." .
А дальше выходит, что ты ожидал ответа вроде "да-нет"


I>>Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области. Обработка данных — императивщина. Управление ресурсами — императивщина. Ввод-вывод — императивщина.

S>Чушь

Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял

I>>Вообще то я не говорил "конкретные задачи конкретным инструментом", а явно указал на область деятельности.

S>Область деятельности не может подразумевать невозможность того или иного подхода к решению.

Цитирую себя "Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области"
Re[79]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 15:47
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Тот мой вопрос не обладает такой фичей, или ты его не понял.


I>

I>"Я подозреваю что ты собеседуешь ДАЛЕКО не на позиции ФП разработчиков. Так почему же ты от них ожидаешь понимания ФП и map-а?"
I>"Не имеют отношения — ответь "нет", чего ты елозишь как уж? "

I> Здесь какое то утверждение на счет твоих подозрений. Потом не понятно откуда берется "почему ..." .

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

I>>>Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области. Обработка данных — императивщина. Управление ресурсами — императивщина. Ввод-вывод — императивщина.

S>>Чушь

I>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял

Рвет в хлам по тактам или по цене решения? ОС это у нас обработка данных?

I>Цитирую себя "Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области"

Кого это ты только что процитировал? Покажи его ненулевой индекс цитирования для начала, потом посмотрим на содержимое цитаты.
Re[80]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.10.12 15:55
Оценка:
Здравствуйте, samius, Вы писали:

I>> Здесь какое то утверждение на счет твоих подозрений. Потом не понятно откуда берется "почему ..." .

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

Покажи это "о другом".

I>>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял

S>Рвет в хлам по тактам или по цене решения? ОС это у нас обработка данных?

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

I>>Цитирую себя "Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области"

S>Кого это ты только что процитировал? Покажи его ненулевой индекс цитирования для начала, потом посмотрим на содержимое цитаты.

Я выделил. 123123.
Re[81]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 08.10.12 16:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>> Здесь какое то утверждение на счет твоих подозрений. Потом не понятно откуда берется "почему ..." .

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

I>Покажи это "о другом".

ты ведь докапывался до этого вопроса

Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?

см http://www.rsdn.ru/forum/philosophy/4918116.1
Автор: Ikemefula
Дата: 05.10.12


I>>>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял

S>>Рвет в хлам по тактам или по цене решения? ОС это у нас обработка данных?

I>По тактам, расходу памяти и тд., а то ведь детские программы для проверки концепций денег не приносят. Второй вопрос похоже означает что список из трех элементов сложноватая концепция,без map не обойтись

Блин, все я слился. Ты не упоминал что готовишь людей, которые не понимают как подставлять значения в формулу, на разработчиков ОС...

I>>>Цитирую себя "Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области"

S>>Кого это ты только что процитировал? Покажи его ненулевой индекс цитирования для начала, потом посмотрим на содержимое цитаты.

I>Я выделил. 123123.

Что это? Индекс цитирования? отуда он?
Re[73]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.12 17:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Ну, давай по кругу — давай сразу интеграл что бы задачи на площать считать. Раз абстракия проще,значит никаких проблем с освоением быть не должно. В каком классе начинают считать задачи на площать ?


G>>Сумма для вычисления площади прямоугольника — абстракция над операцией интегрирования, скрывает ненужные детали.


I>Абстракция это интеграл. А вычисление площади прямоугольника это просто частный случай, где мы сразу берем конкретные формулы.


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

Если взять подмножество функций — константы, то интеграл по отрезку [a,b] равен (b-a)*c или равен произведению сторон. А так как фигра, описываемая этой функцией, есть прямоугольник, то можно применять формулу для любых прямоугольников, независимо от их природы. Это я тебе описал процесс абстракции в рассуждениях.

Конечно реально площадь начали считать раньше, чем интегралы. Но и лямбда-исчисление появилось раньше реальных вычислительных машин.

Есть другой процесс — обобщение, в каком-то смысле он противоположен абстракции. Само определение интеграла является обобщением вычисления площади фигуры под графиком функции и выводится через сумму площадей прямоугольников.

I>>>Для кого сложнее ? Если человек только что сел за программирование, у него нет в голове такой абстракции, как map, а задачи скажем на обработку последовательностей он вообще не решал. for для него это одна из самых первых абстраций, когда он уже попробовал инструкции и ветвления.


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


I>Надо, но их нет. Следоватеьлно, прежде чем давать map надо дать такие абстрации как "последовательность", "итерация".

Да, так и делают. А еще раньше дают рекурсивные функции, а потом рекурсивные структуры данных, чтобы описать последовательности.
И все это укладывается в банальную модель подстановки, которую может понять третьеклассник. А вот изменяемое состояние в цикле с трудом понимают люди с высшим образованием.
Re[79]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 08.10.12 20:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>>>Способы решения задач определяются текущим уровнем развтия технологий применимых к конкретной области. Обработка данных — императивщина. Управление ресурсами — императивщина. Ввод-вывод — императивщина.

S>>Чушь

I>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял


Ну не сливайся ты так. Ведь никто тебе не говорит что надо забыть C++ и писать на чем-то еще. Тебе ведь говорят что не надо на нем учить программировать, это вредно.

Кстати обработка данных обычно декларативна. Самый массовый язык обработки данных — SQL — ни разу не императивен. Что ты имеешь ввиду под управлением ресурсами и вводом-выводом — непонятно.
Re[74]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 07:38
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Если взять подмножество функций — константы, то интеграл по отрезку [a,b] равен (b-a)*c или равен произведению сторон. А так как фигра, описываемая этой функцией, есть прямоугольник, то можно применять формулу для любых прямоугольников, независимо от их природы. Это я тебе описал процесс абстракции в рассуждениях.


OMG ! Интеграл это абстракция более высокого уровня нежели площать прямоугльника, просто по той причине что обобщение и есть инструмент доля получения абстракций более высокого уровня.
У тебя же в наличии КОНКРЕТНЫЕ признаки — фиксированая фигура. Отсюда ясно, что конкретное != абстрактное.


I>>Надо, но их нет. Следоватеьлно, прежде чем давать map надо дать такие абстрации как "последовательность", "итерация".

G>Да, так и делают. А еще раньше дают рекурсивные функции, а потом рекурсивные структуры данных, чтобы описать последовательности.
G>И все это укладывается в банальную модель подстановки, которую может понять третьеклассник. А вот изменяемое состояние в цикле с трудом понимают люди с высшим образованием.

Ну вот и дай рекурсивные структуры данных третьеклассникам, посмотри на результат.
Мне кажется ты путаешь две вещи — изучение некоторой теории и степень освоения оной.
Третьеклассник не умеет подстановки, вобще говоря, это появляется в 4-5 классе в зависимости от программы когда появляются уравнения и простейшие формулы.
Владение подстановкой означает определенное количество умозаключений которое ты можешь выполнять в уме без необходимости помогать себе костылями:
1. получить результат из N операций в уме
2. получить последовательность из N операций для получения нужного результата
В обоих случаях время на выполнение операции должноб быть очень мало. Скажем если на подстановку в простейшее уравнение тебе надо несколько минут, то про лямбдасчисление мпожно забыть. Несколько минут на такую задачу это хорошее время для тех, кто только начинает решать уравнения.
Re[82]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 07:40
Оценка:
Здравствуйте, samius, Вы писали:

S>ты ведь докапывался до этого вопроса

S>

S>Или к тебе на собеседования на позицию разработчика ФП приходят гуру ФП и не понимают map?

S>см http://www.rsdn.ru/forum/philosophy/4918116.1
Автор: Ikemefula
Дата: 05.10.12


И тебе не понятно, почему ответ да-нет не имеет смысла ?
"к тебе на собеседования на позицию разработчика ФП приходят гуру ФП" — "ты перестал"
"и не понимают map" — "пить палёную водку ?"

I>>По тактам, расходу памяти и тд., а то ведь детские программы для проверки концепций денег не приносят. Второй вопрос похоже означает что список из трех элементов сложноватая концепция,без map не обойтись

S>Блин, все я слился.

Вот так будет правильно

I>>Я выделил. 123123.

S>Что это? Индекс цитирования? отуда он?

Требовать индекс цитирования для сообщения на которое ты уже ответил это сильно. Как думаешь, почему мне приходится напоминать тебе некоторые свои ответы ?
Re[83]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.10.12 07:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>И тебе не понятно, почему ответ да-нет не имеет смысла ?

I>"к тебе на собеседования на позицию разработчика ФП приходят гуру ФП" — "ты перестал"
I>"и не понимают map" — "пить палёную водку ?"
Совсем не то же самое. любой ответ на "перстал пить" подразумевает что либо пил, либо еще пьешь. А ответ нет на мой вопрос подразумевает что на позиции разработчика ФП к тебе не приходят гуру, которые не понимают map.

I>>>По тактам, расходу памяти и тд., а то ведь детские программы для проверки концепций денег не приносят. Второй вопрос похоже означает что список из трех элементов сложноватая концепция,без map не обойтись

S>>Блин, все я слился.

I>Вот так будет правильно

Нет, не правильно. Это ирония. Ты все время мечешься между тем что после ВУЗ-а так тяжело входит ИП, но ФП еще тяжелее и тем что бы заставить оппонентов обучать ФП в 3м классе, да так что бы непременно ОС смогли написать.

I>Требовать индекс цитирования для сообщения на которое ты уже ответил это сильно. Как думаешь, почему мне приходится напоминать тебе некоторые свои ответы ?

какие-какие ответы? Я что их зазубривать должен? Было бы в них что ценного...
Re[84]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 08:32
Оценка:
Здравствуйте, samius, Вы писали:

I>>И тебе не понятно, почему ответ да-нет не имеет смысла ?

I>>"к тебе на собеседования на позицию разработчика ФП приходят гуру ФП" — "ты перестал"
I>>"и не понимают map" — "пить палёную водку ?"
S>Совсем не то же самое. любой ответ на "перстал пить" подразумевает что либо пил, либо еще пьешь. А ответ нет на мой вопрос подразумевает что на позиции разработчика ФП к тебе не приходят гуру, которые не понимают map.

Нет, не правильно. Гуру ФП который не понимает map — противоречение. Отсюда ясно, ты сам не понимаешь свой собственный вопрос.

I>>Вот так будет правильно

S>Нет, не правильно. Это ирония. Ты все время мечешься между тем что после ВУЗ-а так тяжело входит ИП, но ФП еще тяжелее и тем что бы заставить оппонентов обучать ФП в 3м классе, да так что бы непременно ОС смогли написать.

Когда я предлагаю давать ФП в третьем классе это сарказм. Я думал это очевидно

I>>Требовать индекс цитирования для сообщения на которое ты уже ответил это сильно. Как думаешь, почему мне приходится напоминать тебе некоторые свои ответы ?

S>какие-какие ответы? Я что их зазубривать должен? Было бы в них что ценного...

на мой взгляд ты пишешь ответы не читая. Потому я просто цитирую себя же что бы не тратить время.
Re[85]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.10.12 08:44
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Нет, не правильно. Гуру ФП который не понимает map — противоречение. Отсюда ясно, ты сам не понимаешь свой собственный вопрос.

Противоречие чему? Тебе не пришло в голову что как "гуру" себя могут позиционировать соискатели?

S>>Нет, не правильно. Это ирония. Ты все время мечешься между тем что после ВУЗ-а так тяжело входит ИП, но ФП еще тяжелее и тем что бы заставить оппонентов обучать ФП в 3м классе, да так что бы непременно ОС смогли написать.


I>Когда я предлагаю давать ФП в третьем классе это сарказм. Я думал это очевидно

А когда ты пишешь что 90% выпускников школ не умеют подставлять значения в формулу — тоже?

S>>какие-какие ответы? Я что их зазубривать должен? Было бы в них что ценного...


I>на мой взгляд ты пишешь ответы не читая. Потому я просто цитирую себя же что бы не тратить время.

Бугога. Цитируя себя ты опять таки зря тратишь время.
Re[86]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 08:54
Оценка:
Здравствуйте, samius, Вы писали:

I>>Нет, не правильно. Гуру ФП который не понимает map — противоречение. Отсюда ясно, ты сам не понимаешь свой собственный вопрос.

S>Противоречие чему? Тебе не пришло в голову что как "гуру" себя могут позиционировать соискатели?

Это ты уже задним числом уточняешь, не годится.

I>>Когда я предлагаю давать ФП в третьем классе это сарказм. Я думал это очевидно

S>А когда ты пишешь что 90% выпускников школ не умеют подставлять значения в формулу — тоже?

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

I>>на мой взгляд ты пишешь ответы не читая. Потому я просто цитирую себя же что бы не тратить время.

S>Бугога. Цитируя себя ты опять таки зря тратишь время.

Да, лучше будет просто тебя игнорировать, экономия будет куда больше.
Re[87]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.10.12 09:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Противоречие чему? Тебе не пришло в голову что как "гуру" себя могут позиционировать соискатели?


I>Это ты уже задним числом уточняешь, не годится.

Ну точно, ты же у нас гуру собеседований, как так к тебе ни разу не приходили самопозиционирующиеся гуру? Задним числом тебе приходится уточнять такие банальности

I>>>Когда я предлагаю давать ФП в третьем классе это сарказм. Я думал это очевидно

S>>А когда ты пишешь что 90% выпускников школ не умеют подставлять значения в формулу — тоже?

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

Это может быть правдой лишь для выпускников со справкой вместо аттестата. Твоя чудовищная часть ошибок в вычислениях просто приведет к тому что средний балл по естественным наукам будет не выше двух с минусом.

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

Все обещаешь...
Re[88]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 09:45
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Противоречие чему? Тебе не пришло в голову что как "гуру" себя могут позиционировать соискатели?


I>>Это ты уже задним числом уточняешь, не годится.

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

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

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

S>Это может быть правдой лишь для выпускников со справкой вместо аттестата. Твоя чудовищная часть ошибок в вычислениях просто приведет к тому что средний балл по естественным наукам будет не выше двух с минусом.

Представь себе, примерно 99% выпускников делает ошибки в вычислениях. Чтото мне кажется и в россии точно так же.

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

S>Все обещаешь...

Здесь нет ни одного обещания, а просто указно мое отношение если рассматривать исключительно с т.з. экономии времени.
Re[75]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 09.10.12 10:55
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ну вот и дай рекурсивные структуры данных третьеклассникам, посмотри на результат.

Опять начинается этот бред про обучение третьеклассников программированию?
I>Мне кажется ты путаешь две вещи — изучение некоторой теории и степень освоения оной.
I>Третьеклассник не умеет подстановки, вобще говоря, это появляется в 4-5 классе в зависимости от программы когда появляются уравнения и простейшие формулы.
Ну вот видите, как здорово. Раз "это" появляется в 4-5 классе, то к 11 уже можно смело рассчитывать на получение результата из N операций в уме.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[89]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.10.12 11:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>"самопозиционирующийся гуру" Разбирайся в своей терминологии в одиночку, мне неинтересно продираться черз твои термины.

Зато смешно как!

S>>Это может быть правдой лишь для выпускников со справкой вместо аттестата. Твоя чудовищная часть ошибок в вычислениях просто приведет к тому что средний балл по естественным наукам будет не выше двух с минусом.


I>Представь себе, примерно 99% выпускников делает ошибки в вычислениях. Чтото мне кажется и в россии точно так же.

Прежде всего "в России" с большой буквы попрошу...
Во вторых, ошибки делают все, но в России их делают не так часто, что бы в 90% можно было сказать что не умеют юзать подстановку. Т.е. какой-то процент выпускников школ (>>10%, но не будут утверждать что близко к 100%) обладают реальными навыками, сдают выпускные/вступительные экзамены самостоятельно, иногда даже досрочно, т.е. не в выпускных классах.
А в мои годы с проблемами в навыках подстановки даже шанс перевестись в очередной класс был ничтожен, т.к. это автоматом бы влекло непроходимость в алгебре/геометрии, физике, химии.

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

S>>Все обещаешь...

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

ок, учту.
Re[90]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 13:32
Оценка:
Здравствуйте, samius, Вы писали:

S>Во вторых, ошибки делают все, но в России их делают не так часто, что бы в 90% можно было сказать что не умеют юзать подстановку. Т.е. какой-то процент выпускников школ (>>10%, но не будут утверждать что близко к 100%) обладают реальными навыками, сдают выпускные/вступительные экзамены самостоятельно, иногда даже досрочно, т.е. не в выпускных классах.

S>А в мои годы с проблемами в навыках подстановки даже шанс перевестись в очередной класс был ничтожен, т.к. это автоматом бы влекло непроходимость в алгебре/геометрии, физике, химии.

Вот если бы скажем, у вас в россии 100% учащихся набирали по ЕГЭ в математике 100% балл...
Чтото мне подсказывает, что 30% набирает большинство, а 100% набирают тоьлко единицы.
Как думаешь, какие причины ?
Re[76]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 13:33
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Ну вот и дай рекурсивные структуры данных третьеклассникам, посмотри на результат.

S>Опять начинается этот бред про обучение третьеклассников программированию?

Бред намного раньше, вот здесь : "все это укладывается в банальную модель подстановки, которую может понять третьеклассник"

I>>Мне кажется ты путаешь две вещи — изучение некоторой теории и степень освоения оной.

I>>Третьеклассник не умеет подстановки, вобще говоря, это появляется в 4-5 классе в зависимости от программы когда появляются уравнения и простейшие формулы.
S>Ну вот видите, как здорово. Раз "это" появляется в 4-5 классе, то к 11 уже можно смело рассчитывать на получение результата из N операций в уме.

Правильно, отсюда понятно что "модель подстановки, которую может понять третьеклассник" есть бред.
Re[91]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 09.10.12 14:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>А в мои годы с проблемами в навыках подстановки даже шанс перевестись в очередной класс был ничтожен, т.к. это автоматом бы влекло непроходимость в алгебре/геометрии, физике, химии.


I>Вот если бы скажем, у вас в россии 100% учащихся набирали по ЕГЭ в математике 100% балл...

Второй раз Россию с маленькой буквы списываю на умышленное намерение оскорбить. Можешь впредь рассчитывать на адекватные намерения лично к тебе, но не к твоим согражданам.
I>Чтото мне подсказывает, что 30% набирает большинство, а 100% набирают тоьлко единицы.
I>Как думаешь, какие причины ?
Причины всякие. Но не та что 90% выпускников не умеют делать подстановку. Если бы ЕГЭ заключался лишь в тестировании подстановки, то 100 баллов брали бы процентов 70-80 выпускников (навскидку) без специальной подготовки.
Re[92]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.10.12 16:54
Оценка:
Здравствуйте, samius, Вы писали:

I>>Чтото мне подсказывает, что 30% набирает большинство, а 100% набирают тоьлко единицы.

I>>Как думаешь, какие причины ?
S>Причины всякие. Но не та что 90% выпускников не умеют делать подстановку. Если бы ЕГЭ заключался лишь в тестировании подстановки, то 100 баллов брали бы процентов 70-80 выпускников (навскидку) без специальной подготовки.

Разумеется. При случа проверь как люди решают задачи. Я вот наверное половине потока в свое время решал электротехнику. Не потому, что там сложно. Просто у людей есть проблемы с простейшими действиями навроде подстановок. Вроде ход решения правильный, а результата нет. В школе это прокатывает, скажем вместо 8 поставят 6 если ошибки не сильно грубые будут. А вот в электротехнике надо получить ответ с точностью до второго знака после запятой и это резко все меняет.
Re[93]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 10.10.12 06:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Разумеется. При случа проверь как люди решают задачи. Я вот наверное половине потока в свое время решал электротехнику. Не потому, что там сложно. Просто у людей есть проблемы с простейшими действиями навроде подстановок. Вроде ход решения правильный, а результата нет. В школе это прокатывает, скажем вместо 8 поставят 6 если ошибки не сильно грубые будут. А вот в электротехнике надо получить ответ с точностью до второго знака после запятой и это резко все меняет.


Очень интересную выборку ты мне предложил. То детки, которые закончили школу более-менее прилично, поступили в вузы, где решали отнюдь не электротехнику. А та часть сливок, что решала с тобой электротехнику — как минимум половина из них обходилась без тебя. Так что пример не в твою пользу.
Re[81]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.10.12 10:11
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


I>>>Чушь у тебя в голове, а это факты — в указаных областях императивный С++ рвет в хлам всех конкурентов, т.е. это основной и практически единсвтенный ЯП. Ну например если ты покажешь скажем ОС писаную не на с++... Ну, ты понял


G>>Ну не сливайся ты так. Ведь никто тебе не говорит что надо забыть C++ и писать на чем-то еще. Тебе ведь говорят что не надо на нем учить программировать, это вредно.


I>А я по твоему предлагаю С++ использовать для обучения ? Дай цитату.


Я не знаю что ты предлагаешь, но тему ты переводишь постоянно. Оставайся в контексте, а то ты на основании рассуждений о C++ делаешь выводы об обучении.

G>>Кстати обработка данных обычно декларативна. Самый массовый язык обработки данных — SQL — ни разу не императивен. Что ты имеешь ввиду под управлением ресурсами и вводом-выводом — непонятно.


I>Обычно императивный код даёт наилучший результат.

Ты представляешь объем и сложность императивного кода, который даст сравнимый с SQL результат?

I>SQL это массовый язык, только покрывает мизерную часть задач обработки данных.

У тебя есть статистика? Мне кажется что по объему кода для обработки данных SQL обошел на несколько кругов всех остальных. Узкоспециализированные решения на конкретных задачах работают быстрее SQL на этих же задачах, но на то эти средства и узкоспециализированные.

I>Ресурсы, ввод-вывод — самый простой пример это драйвера, ОС и тд.

Драйверам скорость не сильно нужна, ограничение по языкам там от низкоуровневости. Что ты имеешь ввиду под ОС — непонятно, ОС — неоднородная вещь. Вот есть оконный манагер для *nix на haskell.
Re[75]: Императивное программирование
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.10.12 10:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, gandjustas, Вы писали:


G>>Если взять подмножество функций — константы, то интеграл по отрезку [a,b] равен (b-a)*c или равен произведению сторон. А так как фигра, описываемая этой функцией, есть прямоугольник, то можно применять формулу для любых прямоугольников, независимо от их природы. Это я тебе описал процесс абстракции в рассуждениях.


I>OMG ! Интеграл это абстракция более высокого уровня нежели площать прямоугльника, просто по той причине что обобщение и есть инструмент доля получения абстракций более высокого уровня.

I>У тебя же в наличии КОНКРЕТНЫЕ признаки — фиксированая фигура. Отсюда ясно, что конкретное != абстрактное.

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


I>>>Надо, но их нет. Следоватеьлно, прежде чем давать map надо дать такие абстрации как "последовательность", "итерация".

G>>Да, так и делают. А еще раньше дают рекурсивные функции, а потом рекурсивные структуры данных, чтобы описать последовательности.
G>>И все это укладывается в банальную модель подстановки, которую может понять третьеклассник. А вот изменяемое состояние в цикле с трудом понимают люди с высшим образованием.

I>Ну вот и дай рекурсивные структуры данных третьеклассникам, посмотри на результат.

I>Мне кажется ты путаешь две вещи — изучение некоторой теории и степень освоения оной.
I>Третьеклассник не умеет подстановки, вобще говоря, это появляется в 4-5 классе в зависимости от программы когда появляются уравнения и простейшие формулы.
Думаешь циклы третьеклассникам легче даются?

I>Владение подстановкой означает определенное количество умозаключений которое ты можешь выполнять в уме без необходимости помогать себе костылями:

I>1. получить результат из N операций в уме
I>2. получить последовательность из N операций для получения нужного результата
I>В обоих случаях время на выполнение операции должноб быть очень мало. Скажем если на подстановку в простейшее уравнение тебе надо несколько минут, то про лямбдасчисление мпожно забыть. Несколько минут на такую задачу это хорошее время для тех, кто только начинает решать уравнения.
Вообще не понял о чем ты. Если вычислительная задача решается подстановкой, то любым другим способом ты будешь решать её дольше.
Re[23]: Императивное программирование
От: artelk  
Дата: 11.10.12 07:28
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, gandjustas, Вы писали:


V>>>Формула для его вычисления ПОШАГОВАЯ. Только это и важно.

G>>Это свойство самой формулы или того как ты эту формулу воспринимаешь?

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


def x = sin(42);
def y = x * 2; // для вычисления y необходимо иметь уже вычесленный x

Функционального программирования не существует. (С)
Опровергни
Re[76]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 09:27
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Я вроде тебе объяснил что обобщение не всегда абстракция, повторить?


Твой пример вообще не имеет никакого отношения к абстракции, т.к. это _конкретный_ способ вычисления площади _конкретной_ фигуры.

I>>Ну вот и дай рекурсивные структуры данных третьеклассникам, посмотри на результат.

I>>Мне кажется ты путаешь две вещи — изучение некоторой теории и степень освоения оной.
I>>Третьеклассник не умеет подстановки, вобще говоря, это появляется в 4-5 классе в зависимости от программы когда появляются уравнения и простейшие формулы.
G>Думаешь циклы третьеклассникам легче даются?

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

I>>В обоих случаях время на выполнение операции должноб быть очень мало. Скажем если на подстановку в простейшее уравнение тебе надо несколько минут, то про лямбдасчисление мпожно забыть. Несколько минут на такую задачу это хорошее время для тех, кто только начинает решать уравнения.

G>Вообще не понял о чем ты. Если вычислительная задача решается подстановкой, то любым другим способом ты будешь решать её дольше.

Короче != понятнее. Я уже устал это объяснять. Вся школьная математика влезет на страничку две в букваре по ВМ.
Коротко ? Да. Понятно ? Смотря кому. Школьникам — нет. доктору физико-математических наук — да, понятнее.
Re[94]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 09:36
Оценка:
Здравствуйте, samius, Вы писали:

I>>Разумеется. При случа проверь как люди решают задачи. Я вот наверное половине потока в свое время решал электротехнику. Не потому, что там сложно. Просто у людей есть проблемы с простейшими действиями навроде подстановок. Вроде ход решения правильный, а результата нет. В школе это прокатывает, скажем вместо 8 поставят 6 если ошибки не сильно грубые будут. А вот в электротехнике надо получить ответ с точностью до второго знака после запятой и это резко все меняет.


S>Очень интересную выборку ты мне предложил. То детки, которые закончили школу более-менее прилично, поступили в вузы, где решали отнюдь не электротехнику.


И давно у вас электротехнику убрали из программы технических вузов ? Или ты в гуманитарном учился ?

>А та часть сливок, что решала с тобой электротехнику — как минимум половина из них обходилась без тебя. Так что пример не в твою пользу.


Я говорю не про свою долю на рынке решений задач по электротехника, а про тот факт, что примерно половина потока не может самостоятельно сделать электротехнику. Ход решения простой, а вычислений много — большинство забивает на это, потому что преподаватель проверяет работу только тогда, когда ответы в задачах совпадут с его собственными. Опаньки !
Сейчас, правда, проще стало, есть куча инструментов где нужно только нарисовать формулы из книги и получить результат. Но вобщем не ясно за счет чего мог вырасти уровень владения математикой среди выпускников. Наоборот, похоже что упал и продолжает падать.
Re[24]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 10:07
Оценка:
Здравствуйте, samius, Вы писали:

V>>На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?

S>В курсе SICP рекурсию дают на лекции 1.

Там где дают рекурсию на этой первой леции, объясняют стек на примере кучи диаграм и тупой императивщины. Вдобавок ко всему весь процесс обучения резко отличается от того, что в странах бывшего ссср, например есть целая пачка ассистентов + вагон практики.
И это еще не все, перед этим самым sicp самые дохлые студенты могут взять необязательный курс попроще, где материал будет даваться попроще и помедленнее.
И еще нюасн — вузы где есть этот sicp являются самыми сильными вузами на планете и их можно сосчитать по пальцам(ну, почти).
Собтсвенно именно ФП в этих вузах начинается после второго курса, да-да и это ни разу не sicp.
Re[95]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 10:07
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Очень интересную выборку ты мне предложил. То детки, которые закончили школу более-менее прилично, поступили в вузы, где решали отнюдь не электротехнику.


I>И давно у вас электротехнику убрали из программы технических вузов ? Или ты в гуманитарном учился ?

Я учился в университете классического типа.

>>А та часть сливок, что решала с тобой электротехнику — как минимум половина из них обходилась без тебя. Так что пример не в твою пользу.


I>Я говорю не про свою долю на рынке решений задач по электротехника, а про тот факт, что примерно половина потока не может самостоятельно сделать электротехнику.

Понимаешь ли, твоя половина потока — это не половина потока абстрактного ВУЗа. Это половина потока конкретного ВУЗа, и без знаний того, кто идет в этот ВУЗ, по какому конкурсу и за какими корочками, обобщать твою половину потока на уровень всех постсоветских выпускников я не собираюсь.

У меня есть под боком ВУЗ (периодически там вспоминают о том что они филиал МИФИ), там в списке предметов есть электротехника. Беда в том, что в этот ВУЗ фактически без конкурса поступают те, кто не поехал за знаниями на большую землю, ну и выпускники школ окрестных деревень. Что бы получить свою 4-ку там надо посетить как минимум 2 лекции и не хамить преподователю на экзамене, т.к. для того что бы не портить карму ВУЗ-а и обеспечить трудоустройство выпускников на местном предприятии был выпущен внутренний приказ не ставить оценок ниже 4.
Так вот, я фактически обобщаю этот ВУЗ на тот, где ты учился со своим пол-потоком. На том основании, что ты рассказываешь об этих полпотоках и плюс наличию электротехники в программе
Ну так вот, ситуация с твоими полпотоками неудивительная, но далеко не везде она такая.
Re[25]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 10:23
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


V>>>На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?

S>>В курсе SICP рекурсию дают на лекции 1.

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

Что-то я там не видел кучи диаграмм и тупой императивщины. Может это все в соседних курсах, врать не буду.

I>И это еще не все, перед этим самым sicp самые дохлые студенты могут взять необязательный курс попроще, где материал будет даваться попроще и помедленнее.

Давайка мы не будем ориентироваться на самых дохлых. Если ориентироваться по ним, то самые живые не будут отличаться от дохлых.
I>И еще нюасн — вузы где есть этот sicp являются самыми сильными вузами на планете и их можно сосчитать по пальцам(ну, почти).
Это вовсе не потому что SICP очень сложный курс, недоступный никому кроме студентов самых сильных ВУЗ-ов.
I>Собтсвенно именно ФП в этих вузах начинается после второго курса, да-да и это ни разу не sicp.
А SICP это уже не ФП?
Так же можно сказать что на математических факультетах математика начинается на втором курсе, когда пройден объем стандартной ВМ в углубленном ракурсе + еще несколько мат. предметов для разминки.
Re[26]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 11:02
Оценка:
Здравствуйте, samius, Вы писали:

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

S>Что-то я там не видел кучи диаграмм и тупой императивщины. Может это все в соседних курсах, врать не буду.

Меня это не удивляет

I>>И это еще не все, перед этим самым sicp самые дохлые студенты могут взять необязательный курс попроще, где материал будет даваться попроще и помедленнее.

S>Давайка мы не будем ориентироваться на самых дохлых. Если ориентироваться по ним, то самые живые не будут отличаться от дохлых.

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

I>>И еще нюасн — вузы где есть этот sicp являются самыми сильными вузами на планете и их можно сосчитать по пальцам(ну, почти).

S>Это вовсе не потому что SICP очень сложный курс, недоступный никому кроме студентов самых сильных ВУЗ-ов.

Вообще говоря SICP именно очень сложный курс. Доступен в основном достаточно сильным студентам. Где те студенты будут учиться — дело десятое.
Насколько я знаю, программистами успешно работают люди, которые вообще программировать не умели пока учились в ВУЗ.

I>>Собтсвенно именно ФП в этих вузах начинается после второго курса, да-да и это ни разу не sicp.

S>А SICP это уже не ФП?

Нет, и никогда не был.

S>Так же можно сказать что на математических факультетах математика начинается на втором курсе, когда пройден объем стандартной ВМ в углубленном ракурсе + еще несколько мат. предметов для разминки.


Правильно, высшая математика только начинается на втором-третьем курсе Скажем на третьем курсе начинается функан.
Re[27]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 11:12
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Что-то я там не видел кучи диаграмм и тупой императивщины. Может это все в соседних курсах, врать не буду.


I>Меня это не удивляет

Я что тут, тебя поудивлять захожу?

I>Ориентироваться надо на тех, кто есть, а не выборку делать. В данном случае этот необязательный курс поднимает нижнюю планку по имеющейся подготовке.

Ты это скажи ректорам тех ВУЗ-ов, которые проводят выборку вступительными экзаменами, ок? Хотя меня не покидает ощущение что в твой ВУЗ попадали минуя этот этап. В том числе те пол-потока.

I>Вообще говоря SICP именно очень сложный курс. Доступен в основном достаточно сильным студентам. Где те студенты будут учиться — дело десятое.

I>Насколько я знаю, программистами успешно работают люди, которые вообще программировать не умели пока учились в ВУЗ.
Да-да, а в вступлении SICP написано что успешно применялся для обучения людей, большей частью не знакомых с программированием, да, аж с 70х годов.

S>>А SICP это уже не ФП?


I>Нет, и никогда не был.

И чем же он тогда по-твоему был?

S>>Так же можно сказать что на математических факультетах математика начинается на втором курсе, когда пройден объем стандартной ВМ в углубленном ракурсе + еще несколько мат. предметов для разминки.


I>Правильно, высшая математика только начинается на втором-третьем курсе Скажем на третьем курсе начинается функан.

тут у тебя тоже пробел
http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%81%D1%88%D0%B0%D1%8F_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0
Re[96]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 11:22
Оценка:
Здравствуйте, samius, Вы писали:

I>>И давно у вас электротехнику убрали из программы технических вузов ? Или ты в гуманитарном учился ?

S>Я учился в университете классического типа.

Электротехники не было ? А физика то хоть была ?

I>>Я говорю не про свою долю на рынке решений задач по электротехника, а про тот факт, что примерно половина потока не может самостоятельно сделать электротехнику.

S>Понимаешь ли, твоя половина потока — это не половина потока абстрактного ВУЗа. Это половина потока конкретного ВУЗа, и без знаний того, кто идет в этот ВУЗ, по какому конкурсу и за какими корочками, обобщать твою половину потока на уровень всех постсоветских выпускников я не собираюсь.

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

S>У меня есть под боком ВУЗ (периодически там вспоминают о том что они филиал МИФИ), там в списке предметов есть электротехника. Беда в том, что в этот ВУЗ фактически без конкурса поступают те, кто не поехал за знаниями на большую землю, ну и выпускники школ окрестных деревень. Что бы получить свою 4-ку там надо посетить как минимум 2 лекции и не хамить преподователю на экзамене, т.к. для того что бы не портить карму ВУЗ-а и обеспечить трудоустройство выпускников на местном предприятии был выпущен внутренний приказ не ставить оценок ниже 4.

S>Так вот, я фактически обобщаю этот ВУЗ на тот, где ты учился со своим пол-потоком. На том основании, что ты рассказываешь об этих полпотоках и плюс наличию электротехники в программе

То есть, занимаешься домыслами по привычке.
Re[97]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 11:34
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>И давно у вас электротехнику убрали из программы технических вузов ? Или ты в гуманитарном учился ?

S>>Я учился в университете классического типа.

I>Электротехники не было ? А физика то хоть была ?

физика хоть была

I>Это поток одной из неплохих специальностей вуза который на голову выше всяких политехов, технологических и прочих провинциальных вузов.

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

S>>Так вот, я фактически обобщаю этот ВУЗ на тот, где ты учился со своим пол-потоком. На том основании, что ты рассказываешь об этих полпотоках и плюс наличию электротехники в программе


I>То есть, занимаешься домыслами по привычке.

почва благодатная для домыслов-то. Большинство выпускников того ВУЗ-а о котором я рассказал тоже считают свой ВУЗ на голову выше прочих И даже считают себя ровней выпускникам головного МИФИ.
Т.е. в моем домысле еще одно совпадение с твоей ситуацией...
Re[98]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 13:00
Оценка:
Здравствуйте, samius, Вы писали:

I>>Электротехники не было ? А физика то хоть была ?

S>физика хоть была

Ну, тогда я спокоен

I>>Это поток одной из неплохих специальностей вуза который на голову выше всяких политехов, технологических и прочих провинциальных вузов.

S>В вузе, который на голову выше такие проблемы с подстановкой? туда при поступлении экзамены сдают, или после армии набирают без конкурса?

Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.
При чем тоже самое и в россии и в любой из стран бывшего ссср.

I>>То есть, занимаешься домыслами по привычке.

S>почва благодатная для домыслов-то. Большинство выпускников того ВУЗ-а о котором я рассказал тоже считают свой ВУЗ на голову выше прочих И даже считают себя ровней выпускникам головного МИФИ.

А у меня все просто — вуз где я учился ведущий в своем профиле. Как ты понимаешь, это много чего меняет.

S>Т.е. в моем домысле еще одно совпадение с твоей ситуацией...


Я и вижу.
Re[28]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 13:12
Оценка:
Здравствуйте, samius, Вы писали:

S>>>Что-то я там не видел кучи диаграмм и тупой императивщины. Может это все в соседних курсах, врать не буду.


I>>Меня это не удивляет

S>Я что тут, тебя поудивлять захожу?

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

I>>Ориентироваться надо на тех, кто есть, а не выборку делать. В данном случае этот необязательный курс поднимает нижнюю планку по имеющейся подготовке.

S>Ты это скажи ректорам тех ВУЗ-ов, которые проводят выборку вступительными экзаменами, ок? Хотя меня не покидает ощущение что в твой ВУЗ попадали минуя этот этап. В том числе те пол-потока.

Проблемы не в конкретном вузе, а в абитуриентах которые идут в ИТ-специальности в странах бывшего СССР не все в порядке, из них 90% знают математику крайне плохо, ансктолько плохо что делают массу ошибок в вычислениях.

Представь себе, для этого не надо учиться в каждом из вузов по 5 лет. Из вузов бывшего СССР где есть ИТ специальности можно вообще разогнать 3/4 и это ничего не изменит

I>>Вообще говоря SICP именно очень сложный курс. Доступен в основном достаточно сильным студентам. Где те студенты будут учиться — дело десятое.

I>>Насколько я знаю, программистами успешно работают люди, которые вообще программировать не умели пока учились в ВУЗ.
S>Да-да, а в вступлении SICP написано что успешно применялся для обучения людей, большей частью не знакомых с программированием, да, аж с 70х годов.

Посмотри что там за вузы были и какой там контигент.

I>>Нет, и никогда не был.

S>И чем же он тогда по-твоему был?

Азы программирования, а функциональщина задвигается специальным предметом, перед которым sicp является обязательным.

I>>Правильно, высшая математика только начинается на втором-третьем курсе Скажем на третьем курсе начинается функан.

S>тут у тебя тоже пробел
S>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%81%D1%88%D0%B0%D1%8F_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0

Это все так себе, большая часть этого хлама просто школьная математика. Высшая она сильно условно.
Re[99]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 13:18
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.

I>При чем тоже самое и в россии и в любой из стран бывшего ссср.
Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

S>>почва благодатная для домыслов-то. Большинство выпускников того ВУЗ-а о котором я рассказал тоже считают свой ВУЗ на голову выше прочих И даже считают себя ровней выпускникам головного МИФИ.


I>А у меня все просто — вуз где я учился ведущий в своем профиле. Как ты понимаешь, это много чего меняет.

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

I>Я и вижу.

и я вижу
Re[84]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 13:24
Оценка:
Здравствуйте, Sinclair, Вы писали:

I>>Ты внятно ответь на вопрос — где я предлагаю использовать С++ для обучения ? Есть простой факт — С++ крайне востребован в определенных областях, котрые крайне актуальны.

S>Это не делает его идеальным языком для обучения программированию. И даже идеальным языком для программирования вообще.

Для обучения программированию конечно же это плохой язык. Зато востребованность С++ означает, что студенты должны как минимум освоить этот С++, а начинать программуху конечно же лучше с другого языка.


I>>Представляю. SQL обычно используется чисто для выборки даннх и предварительной обработки. Основной процессинг всегда на сервере. Например потому, что для процессинга нужны данные из разных источников или же нужны все данные и сразу.

S>Простите, но настоящего SQL вы никогда не видели. "Основной процессинг". "Чисто для выборки данных". Не смешите меня, пожалуйста.
S>Даже если не пользоваться group by с having и подзапросами, а только джойнами, where и order by, то вы употеете делать аналогичную "чисто выборку данных" на императивном языке.

Это мизерная часть всех сценариев.

I>>В чем то ты прав, когда винда зависает от того, что лоток привода закрывается, то часто это означает, что драйвер писал программист который считал что драйверу скорость не нужна.

S>Вообще-то нет. Как правило, это означает, что драйвер писал программист, считающий скорость важнее корректности.
S>Чтобы понять, что вы пишете чушь, нужно представлять скорости современного железа. За время "закрытия лотка" процессор успевает намолотить столько, что заметных задержек в UI не даст даже JavaScript, интерпретируемый интерпретатором, написанным на SQL.
S>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать мало-
мальски интересных инвариантов.

Ну ладно, с лотком ты прав


I>>Вот оконному манагеру скорость точно не нужна, ибо он не занимается низкоуровневыми вещами, а они, в свою очередь, написаны на мега-оптимизированом инструменте.

S>Скорость и низкоуровневость связаны между собой вовсе не так, как вы полагаете — если судить вот по этому бредовому утверждению.

оконные менеджеры испокон веков писались на тормозах разных сортов и ни разу это не становилось проблемой
Re[100]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 11.10.12 13:37
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.

I>>При чем тоже самое и в россии и в любой из стран бывшего ссср.
S>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

Кто ж виноват вашей специфике ?

I>>А у меня все просто — вуз где я учился ведущий в своем профиле. Как ты понимаешь, это много чего меняет.

S>Конечно ничего не меняет. ВУЗ о котором я пишу (кстати, вот здесь) — тоже ведущий в своем роде, в подготовке кадров для ядерного центра. Не хухры-мухры

Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.
Re[29]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 13:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Я что тут, тебя поудивлять захожу?


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

Ну тогда ладно, удивляйся дальше.

I>Проблемы не в конкретном вузе, а в абитуриентах которые идут в ИТ-специальности в странах бывшего СССР не все в порядке, из них 90% знают математику крайне плохо, ансктолько плохо что делают массу ошибок в вычислениях.

Идут-то ладно, как же они попадают в эти ВУЗ-ы? Ты все увиливаешь от ответов на тему экзаменов...

I>Представь себе, для этого не надо учиться в каждом из вузов по 5 лет. Из вузов бывшего СССР где есть ИТ специальности можно вообще разогнать 3/4 и это ничего не изменит

Ну как же не изменит? Изменит. Тогда 3/4 не получат диплом о в/о, за которым собственно они туда пошли.

S>>Да-да, а в вступлении SICP написано что успешно применялся для обучения людей, большей частью не знакомых с программированием, да, аж с 70х годов.


I>Посмотри что там за вузы были и какой там контигент.

Нормальный контигент такой.

I>>>Нет, и никогда не был.

S>>И чем же он тогда по-твоему был?

I>Азы программирования, а функциональщина задвигается специальным предметом, перед которым sicp является обязательным.

С тем что это АЗЫ — я согласен. А с тем что это не функциональные азы — нет.

S>>http://ru.wikipedia.org/wiki/%D0%92%D1%8B%D1%81%D1%88%D0%B0%D1%8F_%D0%BC%D0%B0%D1%82%D0%B5%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0


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

Ну это смотря для кого. Как всегда, составители программы для ВУЗ-ов и википедии забыли спросить твоего мнения.
Re[101]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 11.10.12 13:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.


I>Кто ж виноват вашей специфике ?

точно не я

I>Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.

А я и не говорил что он близко ИТ. Зато там есть электротехника и всегда найдется полпотока тупых
Re[24]: Императивное программирование
От: vdimas Россия  
Дата: 11.10.12 14:05
Оценка:
Здравствуйте, artelk, Вы писали:

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


A>def x = sin(42);

A>def y = x * 2; // для вычисления y необходимо иметь уже вычесленный x

A>Функционального программирования не существует. (С)

A>Опровергни


Покажи ветвление.
Re[24]: Императивное программирование
От: vdimas Россия  
Дата: 11.10.12 14:26
Оценка:
Здравствуйте, Sinclair, Вы писали:


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

S>Полная чушь. Никакой фундаментальности тут нет.

Боюсь, доказать ты это не сможешь. А я уже доказывал рядом не раз. См. что есть if в комбинаторном базисе I/K.


S>Домашнее задание:

S>1. выяснить, как работает ускоренная схема арифметического сложения, понять, почему там аргументы вычисляются до предиката, а не после.

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

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


S>2. вывести граничные условия для случая, когда порядок вычисления аргументов функции ветвления обязан быть таким, как вы думаете, что он должен быть всегда.


Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?

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


S>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.


Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
Хорошо себя чувствуешь?
Re[24]: Императивное программирование
От: vdimas Россия  
Дата: 11.10.12 14:32
Оценка:
Здравствуйте, samius, Вы писали:

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

S>Пошаговая как и WHERE в SQL

Увы, в where не говорится, как получить результат, а только описывают характеристики результата. SQL-выражение является аналогом исходного уравнения. Зато некая последовательность операций РА вполне может являться решением уравнения, заданного в SQL. Эту последовательность операций РА можно будет разложить на шаги проще простого.

V>>На каком уроке по программированию на ФП надо давать рекурсию? На 30-м?

S>В курсе SICP рекурсию дают на лекции 1.

Этот курс даётся на базе уже некоторого предварительного образования, то бишь читается не на 1-м курсе. В любом случае, речь как минимм о людях, уже закончивших школу.


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

S>Ближе к началу второй половинки 1-ой лекции

И че? На 3-м курсе на первых же лекциях по устройству ОС давали все популярные примитивы синхронизации. Значит ли это, что такую лекцию поймет ученик, скажем, 5-6-го класса?


V>>Лучше устыдись своего примера насчет чисел Фибоначи. Исходная формула описывает получение следующих элементов ряда из предыдущих. Т.е. вместо твоего стыда надо было так:

V>>F[n] = F[n-1] + F[n-2],
V>>где F никакая не ф-ия, а значение элемента ряда.
S>То что F не функция, тебе придется показать формально.

Мне не надо никому ничего показывать, я так ставлю условие задачи, вводя отношения м/у [i]элементами
ряда, а не м/у ф-иями, описывающими эти элементы. Прочувствуйте разницу, как говорится. И, хотя формально это одно и то же (ведь символьная подстановка ничего не меняет), но в моем случае рассуждение отталкивается от конкретных значений элемента ряда, в то время как в варианте ф-ии F(x) присутствует дополнительная абстракция — подстановочный символ. Итого, до изучения основ декомпозиции, ученик эту задачу не решит в первом варианте, зато решит в моём. Помня себя, когда-то впервые увидев Бейсик в школе, я решал подобные задачи уже через 5 мин после изучения 4-х основных операторов Бейсика и нащелкал подобных задач к концу урока чуть ли не с десяток. Как раз упоминавшаяся задача с решением квадратного уравнения была первой. То бишь, я еще понятия о декомпозиции не имел, но уже "схватил", как всё работает и как этим орудовать, извлекая некую пользу и имея возможность выводить на печать результаты промежуточных вычислений. В ФП это невозможно.

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

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

Далее. Берем лямбды. Лямбда не может вызывать себя рекурсивно. Т.е. уже на совсем ранних уроках по ФП необходимо какое-то понимание из раздела комбинаторики ф-ий (как минимум Y-комбинатор) для целей построения банальных циклов "по-месту". А это опять и снова требует некий далеко ненулевой бэкграунд (попробуй объяснить ребенку это). А ведь речь по-прежнему о банальном цикле, который в императивном Бейсике/Паскале можно писать "по-месту" безо-всяких знаний о декомпозиции и комбинаторике.

Кароч, если речь всё еще об обучении детей, то тут даже обсуждать нечего. ФП непригоден для неподготовленных людей.
Re[84]: Императивное программирование
От: vdimas Россия  
Дата: 11.10.12 14:50
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Даже если не пользоваться group by с having и подзапросами, а только джойнами, where и order by, то вы употеете делать аналогичную "чисто выборку данных" на императивном языке.


Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))

S>А обеспечение ACID для типичной OLTP-транзакции вам будет стоить седых волос в неожиданных местах.


Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.


S>Зависания — это от того, что говнодрайвер перешёл в такое состояние, которого его автор никак не ожидал. Это как раз строго от императивности, т.к. в ней невозможно доказать мало-мальски интересных инвариантов.


Какая восхитительная чушь. Тебе врожденную эквивалентность ЛИ и МТ напомнить или сам догадался уже? А то, что уровни описания подробностей задач в императиве и на современных ФП-языках одинаковы тоже напомить? При чем тут инварианты, если речь всего-навсего о том, что не ввели промежуточные состояния в АПИ — "закрытие в процессе", "открытие в процессе"? Эти промежуточные состояния точно так же могли не ввести в ФП-программу... И кстате, драйвер обрабатывает сообщения из произвольных физических потоков в кольце ядра, то бишь, требуется совместный доступ к расшаренным данным (флагам) из нескольких потоков. Как это сделать на ФП? )))
Re[25]: Императивное программирование
От: artelk  
Дата: 11.10.12 14:51
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


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


A>>def x = sin(42);

A>>def y = x * 2; // для вычисления y необходимо иметь уже вычисленный x

A>>Функционального программирования не существует. (С)

A>>Опровергни

V>Покажи ветвление.

Зачем?

Вот тут
Автор: vdimas
Дата: 09.10.12
ты пишешь:

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе


Далее ты говоришь, что операция ветвления "пошаговая по свой природе". Т.е. операций ветвления не может быть в ФП, так?

Операция ветвления пошаговая по своей природе, поскольку "в любой точке ветвления необходимо иметь уже вычисленный аргумент-предикат".
Я показал другой случай, когда "необходимо иметь уже вычисленный" параметр. Приведенного кода, по твоей логике, не может быть в ФП, я ничего не путаю?
Re[85]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.12 05:32
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Наверно именно поэтому, всё более-менее заметные в индустрии СУБД написаны на императивных языках. )))

А ещё все программы на десктопе исполняются вообще одним и тем же процессором с одной и той же системой команд, и она, естественно, императивна.
Этого достаточно, чтобы понять, почему ваш аргумент не имеет в данном контексте никакого смысла, или нужно разжевать?
V>Наоборот. ФП не умеет исключительные ситуации, не умеет синхронизации, не умеет откатов, не умеет RAII. Это всё пишут только на императиве.
И здесь вы опять путаете тёплое с мягким, т.е. формулировку задачи с её решением.

V>Какая восхитительная чушь. Тебе врожденную эквивалентность ЛИ и МТ напомнить или сам догадался уже? А то, что уровни описания подробностей задач в императиве и на современных ФП-языках одинаковы тоже напомить? При чем тут инварианты, если речь всего-навсего о том, что не ввели промежуточные состояния в АПИ — "закрытие в процессе", "открытие в процессе"? Эти промежуточные состояния точно так же могли не ввести в ФП-программу... И кстате, драйвер обрабатывает сообщения из произвольных физических потоков в кольце ядра, то бишь, требуется совместный доступ к расшаренным данным (флагам) из нескольких потоков. Как это сделать на ФП? )))

Омг, омг. Столько чуши в одном абзаце, прямо праздник какой-то. Даже не знаю, на что прокомментировать. Ну, на последнюю фразу отвечу: вот вам, скажем, слово Эрланг что-нибудь говорит? В нём и есть ответ, как сделать обработку сообщений "из произвольных физических потоков" на ФП. А то, что для этого нужен "совместный доступ к расшаренным данным" — это вы уже сами придумали, и сами над собой посмеялись.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.10.12 05:59
Оценка:
Здравствуйте, vdimas, Вы писали:

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

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

V>Или ты имел ввиду переупорядочивание + спекулятивные вычисления в современных процах? Это не есть ускоренное сложение, это именно спекулятивные вычисления, которые могут иметь место в случае наличия свободных ресурсов внутри проца (свободных арифметических блоков). В общем, это не принципиально для обсуждаемого, т.к. результаты неверной ветки отбрасываются (либо сбрасывается конвейер). Не принципиально потому, что в проце нет никакой рекурсии и быть не может... в отличие от ФП, где одна из веток обычно останавливает рекурсию. Без упорядочивания вычислений на ветвлении ты получишь зацикливание уже на банальной ф-ии вычисления факториала.

Ну, вот видите, от "фундаментального" требования, т.е. выполняемого всегда, мы внезапно перешли к "обычно".
Кстати, вас не затруднит продемонстрировать мне "получение зацикливания" на вычислении факториала?

V>Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?

S>>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.
V>Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
V>Хорошо себя чувствуешь?
Я — прекрасно. Вы уже нашли этот случай, правда, не смогли этого заметить. Действительно, без ычисления предиката можно обойтись тогда, когда выбираемые ветки одинаковы. Чтобы вы не продолжали нести чушь про неисправный компилятор, я вам на пальцах поясню, откуда могут возникать такие случаи.
Поскольку в ФП функции являются "гражданами первого класса", наш код не обязан иметь полностью статическую структуру. Некий алгоритм может быть сформулирован для общего случая, и параметризован функциями. Для частных применений параметры могут быть в том числе и одинаковыми. Ну вот, скажем, дурацкий пример — имеем алгоритм раскраски таблицы в UI. В общем случае мы имеем разные цвета для чётных/нечётных строк, в частном случае конкретной дизайн-схемы мы скармливаем в него "белый"/"белый".
В итоге вычисление предиката внутри общего кода становится избыточным.

Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.

А ваши аргументы на эту тему я уже читал — и в прошлый раз они были вполне смехотворны. Вы пускаетесь в рассуждения о производительности, которые на микроуровне вообще не имеют смысла — потому, что в реальном случае мы имеем не изолированный предикат, а более-менее сложную функцию, скомбинированную из других функций, и так далее. И здесь оптимальный порядок вычислений "листьев" может быть нетривиальным.
Вы же в курсе, почему современные ФП-языки ведут себя лучше, чем Шлемиель, при порождении ряда Фибоначчи, несмотря на явно рекурсивное описание?
Ну и это же является намёком на то, что не имеет смысла говорить о конкретном императивном решении для вычисления отдельной функции. Вычислитель не обязан быть "всегда энергичным" или "всегда ленивым". Это же ФП — отсутствие побочных эффектов даёт нам свободу в упорядочивании.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: Императивное программирование
От: artelk  
Дата: 12.10.12 07:38
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, vdimas, Вы писали:


S>Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.

+1

Более того, если одна из F1/F2 будет (_|_), то ничего страшного не должно произойти. Ошибка будет, если (_|_) передастся в функции IO, после того, как по предикату выберется эта ветка.
Re[25]: Императивное программирование
От: artelk  
Дата: 12.10.12 08:07
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Покажи ветвление.


Вот, кстати, скажи, здесь есть пошаговость:
abs(x) { if x<0 -x else x }

?

А тут:
abs(x) { 
  def b = (x < 0) :> int; // Cast
  b*(-x) + (1-b)*x 
}

?
Re[86]: Императивное программирование
От: vdimas Россия  
Дата: 12.10.12 08:08
Оценка:
Здравствуйте, Sinclair, Вы писали:


V>>А то, что уровни описания подробностей задач в императиве и на современных ФП-языках одинаковы тоже напомить?


Кстате, от ответа на этот вопрос ты старательно уходишь уже 3-й раз на моей памяти.


V>>При чем тут инварианты, если речь всего-навсего о том, что не ввели промежуточные состояния в АПИ — "закрытие в процессе", "открытие в процессе"? Эти промежуточные состояния точно так же могли не ввести в ФП-программу...


И на единственное техническое замечание по самому драйверу тоже ес-но ответить нечего. ЧТД.


И кстате, драйвер обрабатывает сообщения из произвольных физических потоков в кольце ядра, то бишь, требуется совместный доступ к расшаренным данным (флагам) из нескольких потоков. Как это сделать на ФП? )))
S>Омг, омг. Столько чуши в одном абзаце, прямо праздник какой-то. Даже не знаю, на что прокомментировать.

Дык, ты уже последние полсотни постов не знаешь что комментировать. Тема зачетная. Упёрся в тупик, однако...


S>Ну, на последнюю фразу отвечу: вот вам, скажем, слово Эрланг что-нибудь говорит? В нём и есть ответ, как сделать обработку сообщений "из произвольных физических потоков" на ФП.


ЧТД. Очередное проявление твоей поверхностности. Медитировать на выделенным до бесконечности.


S>А то, что для этого нужен "совместный доступ к расшаренным данным" — это вы уже сами придумали, и сами над собой посмеялись.


Я-то прекрасно знаю, над чем я смеюсь. Тут кто-то на весь интернет показывает своё невладение даже базовыми механизмами работы современных ОС на SMP-машинках. За Эрланг отдельное спасибо. Можно было с тем же успехом предложить Оберон или Барток как язык для исходника драйвера под вполне конкретную названную ОС. Возьми себе за труд хоть немного порассуждать в эту область, глядишь, и понял бы, в чем именно заключается мой вопрос.

Ну что? Еще одна попытка?
Re[26]: Императивное программирование
От: vdimas Россия  
Дата: 12.10.12 11:00
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

S>Совершенно верно. Про "не содержит предикатов вообще" — это вы сильно высказались. Вам понятно, что для сложения блока разрядов есть две ветки — с наличием переноса и без него?

Гы, ну да, любая схема — это некое материализованное логическое выражение по-определению! сильно сказано!

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

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


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


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

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

S>К счастью, так никто не делает.


Да когда б ты уже отучился делать заявления, одно смелее другого?
Тебя же люди читают...


V>>Или ты имел ввиду переупорядочивание + спекулятивные вычисления в современных процах? Это не есть ускоренное сложение, это именно спекулятивные вычисления, которые могут иметь место в случае наличия свободных ресурсов внутри проца (свободных арифметических блоков). В общем, это не принципиально для обсуждаемого, т.к. результаты неверной ветки отбрасываются (либо сбрасывается конвейер). Не принципиально потому, что в проце нет никакой рекурсии и быть не может... в отличие от ФП, где одна из веток обычно останавливает рекурсию. Без упорядочивания вычислений на ветвлении ты получишь зацикливание уже на банальной ф-ии вычисления факториала.

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

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


S>Кстати, вас не затруднит продемонстрировать мне "получение зацикливания" на вычислении факториала?


Издеваешься?

uint fact(uint arg) {
  if(x < 2)
    return 1;
  else
    return arg * fact(arg - 1);
}


При вычислении второй ветки раньше предиката (x<2), легко уйти в вечный цикл. Предложи непротиворечивую логику по ограничению потребления ресурсов такими "ложными" вычислениями на уровне компилятора?


V>>Легко — это различимость успешной и неуспешной ветки. Иначе, зачем бы нам тогда предикат?

S>>>3. найти случаи, в которых можно вообще обойтись без вычисления предиката.
V>>Т.е. в теме обсуждения упорядочивания вычислений на предикате я должен искать случаи, когда предикат не нужен? )))
V>>Хорошо себя чувствуешь?
S>Я — прекрасно. Вы уже нашли этот случай, правда, не смогли этого заметить.

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

S>Действительно, без ычисления предиката можно обойтись тогда, когда выбираемые ветки одинаковы. Чтобы вы не продолжали нести чушь про неисправный компилятор, я вам на пальцах поясню, откуда могут возникать такие случаи.


Не надо метать тут банальности. В любом случае, где предикат НЕ нужен и это понятно ДО вычисления, компилятор должен его выкидывать, а не пытаться исполнять две ОДИНАКОВЫЕ ветки в произвольном порядке.

S>Поскольку в ФП функции являются "гражданами первого класса", наш код не обязан иметь полностью статическую структуру. Некий алгоритм может быть сформулирован для общего случая, и параметризован функциями. Для частных применений параметры могут быть в том числе и одинаковыми. Ну вот, скажем, дурацкий пример — имеем алгоритм раскраски таблицы в UI. В общем случае мы имеем разные цвета для чётных/нечётных строк, в частном случае конкретной дизайн-схемы мы скармливаем в него "белый"/"белый".

S>В итоге вычисление предиката внутри общего кода становится избыточным.

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

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

S>Теперь можно вернуться к предыдущему вопросу — про упорядочивание вычислений. Очевидно, что с точки зрения ФП, можно вычислить любую вычислимую функцию. То есть, если у меня есть IF(P, F1, F2), то проблемы возникнут только в том случае, если одна из F1/F2 невычислима. В остальных случаях вычисление их до предиката вполне себе безопасно — ведь это не меняет никакого состояния.


Ес-но. Речь только о том, сколько оборотов от 0-ля до UInt::MaxValue прокрутит приведенный факториал, используя каждый раз ложную ветку, прежде чем "кто-то третий" его остановит. )))

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

S>Вы же в курсе, почему современные ФП-языки ведут себя лучше, чем Шлемиель, при порождении ряда Фибоначчи, несмотря на явно рекурсивное описание?
S>Ну и это же является намёком на то, что не имеет смысла говорить о конкретном императивном решении для вычисления отдельной функции. Вычислитель не обязан быть "всегда энергичным" или "всегда ленивым". Это же ФП — отсутствие побочных эффектов даёт нам свободу в упорядочивании.

Я не отрицал никакую свободу ни разу. Я лишь хочу увидеть механизмы (формальные, ес-но), которыми эти упорядочивания регулируются. А то это уже начинает походить на раннего тебя во времена выхода дотнета — обещания ни о чём. Ты бы взял на досуге исходники компиляторов современных "оптимизирующих" ФП-языков (Хаскеля, ОКамла, Схемы) и посмотрел, что реально они генерят и из чего исходят на этапе редукции. Очень, знаешь ли, сие полезное действо возвращает с небес на землю.

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

И да, сравнение со спекулятивными вычислениями внутри проца — это плохое сравнение. Плохое хотя бы потому, что в проце сплошная динамика. Шедуллер команд располагает сведениями, какая ячейка памяти сидит в кеше какого уровня и сидит ли вообще, есть ли свободные АЛУ и т.д. и т.п. Всё это "по месту" и всё это однократно, без рекурсий. Другое дело компилятор, у которого только статическая информация и который должен генерить код, подходящий для совершенно разных мгновенных условий. Именно отталкиваясь от статической компиляции я утверждаю, что все эти вещи дальше рассуждений в обозримом будущем пойти не могут. Именно так, несмотря на твои повторы одних и тех же банальностей об отсутствии побочных эффектов. Ты ведь не Америку каждый раз открываешь, твердя про отсутствие побочных эффектов, скорее, ровно наоборот. Имею ввиду, что в любом современном компиляторе с ФП-языка такое поведение, будь оно замечено, будет помечено как баг и обязательно исправлено. Се ля ви.
Re[26]: Императивное программирование
От: vdimas Россия  
Дата: 12.10.12 11:17
Оценка:
Здравствуйте, artelk, Вы писали:


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


A>>>def x = sin(42);

A>>>def y = x * 2; // для вычисления y необходимо иметь уже вычисленный x

A>>>Функционального программирования не существует. (С)

A>>>Опровергни

V>>Покажи ветвление.

A>Зачем?

A>Вот тут
Автор: vdimas
Дата: 09.10.12
ты пишешь:

A>

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе


Ясно.
Тогда тебе придется пояснить, что именно ты привел. Это вычисления переменных, или объявления ф-ий (то бишь отсутствие всяких вычислений до вызова этих ф-ий)?
Если первое, то это никакое не ФП, а код на каком-нить мультипарадигменном языке, типа OCaml-а или Nemerle. Если второе, то обсуждать можно было бы только вызов ф-ий, а не их декларацию.
Re[26]: Императивное программирование
От: vdimas Россия  
Дата: 12.10.12 11:24
Оценка:
Здравствуйте, artelk, Вы писали:

V>>Покажи ветвление.


A>Вот, кстати, скажи, здесь есть пошаговость:

A>
A>abs(x) { if x<0 -x else x }
A>

A>?

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

A>А тут:

A>
A>abs(x) { 
A>  def b = (x < 0) :> int; // Cast
A>  b*(-x) + (1-b)*x 
A>}
A>

A>?

А тут итоговое выражение вычисляется в произвольном, недоступном тебе, порядке.

Ты показал правильный пример. Например, я всегда пишу здесь, что ветвление зло для современных процов, поэтому где можно, ветвления необходимо заменять вычислениями (как ты показал) или даже +1 косвенностью (например, виртуальный вызов в ООП или паттерны поведения, для ФП — лямбды и прочие Ф). Хотя, с косвенностью надо быть внимательнее со сценариями, т.к. при распространении констант ветвление иногда нивелируется еще на этапе компиляции, то бишь предикат исчезает, а +1 косвенность — нет... но это уже дело десятое, главное понимать, что проблема с ветвлением реально существует на современной аппаратуре.
Re[27]: Императивное программирование
От: artelk  
Дата: 12.10.12 11:45
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, artelk, Вы писали:


A>>Вот тут
Автор: vdimas
Дата: 09.10.12
ты пишешь:

A>>

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе


V>Ясно.

V>Тогда тебе придется пояснить, что именно ты привел. Это вычисления переменных, или объявления ф-ий (то бишь отсутствие всяких вычислений до вызова этих ф-ий)?
V>Если первое, то это никакое не ФП, а код на каком-нить мультипарадигменном языке, типа OCaml-а или Nemerle. Если второе, то обсуждать можно было бы только вызов ф-ий, а не их декларацию.

Это код на неком ленивом функциональном языке.
Ф-я main выглядит как-то так:
main :: IO ()
main = print y

, что приводит к вычислению значения y.
Re[28]: Императивное программирование
От: vdimas Россия  
Дата: 14.10.12 07:49
Оценка:
Здравствуйте, artelk, Вы писали:

A>>>Вот тут
Автор: vdimas
Дата: 09.10.12
ты пишешь:

A>>>

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе


V>>Ясно.

V>>Тогда тебе придется пояснить, что именно ты привел. Это вычисления переменных, или объявления ф-ий (то бишь отсутствие всяких вычислений до вызова этих ф-ий)?
V>>Если первое, то это никакое не ФП, а код на каком-нить мультипарадигменном языке, типа OCaml-а или Nemerle. Если второе, то обсуждать можно было бы только вызов ф-ий, а не их декларацию.

A>Это код на неком ленивом функциональном языке.


В таком случае это второй вариант — декларация ф-ий.

A>Ф-я main выглядит как-то так:

A>
A>main :: IO ()
A>main = print y
A>

A>, что приводит к вычислению значения y.

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

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

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

Ну или в некоторых мультипарадигменных ФП-языках, которые не являются полностью чистыми (типа Хаскеля), можно получать пошаговость, т.е. явно заданный порядок вычислений, на специальных императивных механизмах, типа монады IO.
Re[27]: Императивное программирование
От: vdimas Россия  
Дата: 14.10.12 08:13
Оценка:
Здравствуйте, artelk, Вы писали:

A>Более того, если одна из F1/F2 будет (_|_), то ничего страшного не должно произойти.


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


A>Ошибка будет, если (_|_) передастся в функции IO, после того, как по предикату выберется эта ветка.


Подумав 5 мин можно обратить такую "ошибку" на пользу, считай в "точку синхронизации" в вашей воображаемой системе распараллеливаемых/спекулятивных вычислений. Это и так всё понятно...

Но, прикол ситуации в том, что на сегодня императив рулит гораздо больше в плане спекулятивных вычислений, чем ФП, т.к. обычное переупорядочивание независимых вычислений в императиве, выполняемое современными компиляторами С++, например, всегда вычисляет такие вещи, которые должны были быть вычислены в любом случае. Теперь сравни с холостой тратой ресурсов на вычислении ложных веток непонятной глубины.
Re[102]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 08:51
Оценка:
Здравствуйте, samius, Вы писали:

I>>Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.

S>А я и не говорил что он близко ИТ. Зато там есть электротехника и всегда найдется полпотока тупых

Если не ИТ, то для чего ты пример приводил, для весу ?
Re[30]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 09:16
Оценка:
Здравствуйте, samius, Вы писали:

I>>Проблемы не в конкретном вузе, а в абитуриентах которые идут в ИТ-специальности в странах бывшего СССР не все в порядке, из них 90% знают математику крайне плохо, ансктолько плохо что делают массу ошибок в вычислениях.

S>Идут-то ладно, как же они попадают в эти ВУЗ-ы? Ты все увиливаешь от ответов на тему экзаменов...

Очень просто — минимальная планка в вузах испокон веков на уровне где то середнячка из сельской школы.
На примере(просто пример для иллюстрации), есть 50 бюджетных мест. Есть 100 желающих. Миниальный уровень — скажем, решение 3х задач уровня А в сборнике Сканави. 40 человек решает 4 задачи, 60 — 3.
Итого, 50 мест будет распределено таким образом — 40 из тех, кто решил 4 задачи и 10 кто осилил только 3. Еще сюда можно добавить льготы различные, например для сельских, взятки и разно непотребство, то картина получается не самая радужная.

I>>Представь себе, для этого не надо учиться в каждом из вузов по 5 лет. Из вузов бывшего СССР где есть ИТ специальности можно вообще разогнать 3/4 и это ничего не изменит

S>Ну как же не изменит? Изменит. Тогда 3/4 не получат диплом о в/о, за которым собственно они туда пошли.

То есть, разница будет только в наличии диплома ? Спасибо, это и есть "ничего".

I>>Посмотри что там за вузы были и какой там контигент.

S>Нормальный контигент такой.

Не нормальный, в том то и дело.

I>>Азы программирования, а функциональщина задвигается специальным предметом, перед которым sicp является обязательным.

S>С тем что это АЗЫ — я согласен. А с тем что это не функциональные азы — нет.

Этот сикп к слову уже давно не сикп. Смотри сам http://mit.edu/6.01/www/calendar.html
Там даже программуха так, побочный эффект, сразу начинают с роботов всяких, автоматов и все это на императивном питоне.
Re[100]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 09:24
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я тебе страшное скаже, проблемы не только с подстановкой, а вообще с математикой примерно у 90% тех кто поступает вообще в технические вузы в т.ч на ИТ.

I>>При чем тоже самое и в россии и в любой из стран бывшего ссср.
S>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

Ты предлагаешь из списка вузов вычеркнуть часть, котоаря тебе неудобна, и оставшиеся рассматривать как вузы ?

С таким подходом конечно же все мои рассуждения теряют смысл, ибо я говорю о вузах вообще, а ты говоришь только о какой части всех вузов, которая лично тебе удобна.
Re[103]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 11:20
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.

S>>А я и не говорил что он близко ИТ. Зато там есть электротехника и всегда найдется полпотока тупых

I>Если не ИТ, то для чего ты пример приводил, для весу ?


По ключевым совпадениям. Ну а потом, не думаешь ли ты что в ИТ работают только те кто закончил ИТ?
Re[30]: Императивное программирование
От: vdimas Россия  
Дата: 15.10.12 11:35
Оценка:
Здравствуйте, artelk, Вы писали:

V>>В таком случае это второй вариант — декларация ф-ий.

A>Прекрасно, а чем if не функция?

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

Св-ва ленивости, однако. )))
(Если ни одна из веток if не нужна, то и предикат вычислен НЕ будет.)

V>>В общем, курить бета-редукцию.

A>Тут, видимо, требуется какая-то особая техника курения.

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


V>>Явные зависимости ф-ий ничего не значат в ФП в плане пошаговости, то бишь твой коммент в коде "// для вычисления y необходимо иметь уже вычисленный x" попахивает непониманием. Нет никакой такой необходимости после подстановки символов.

A>Ну тогда и "необходимо иметь уже вычисленный аргумент-предикат" так же попахивает непониманием. Нет никакой такой необходимости после подстановки символов.

Это только если предикат оперирует compile-time данными и может быть вычислен в compile-time. То бишь это уже вторая попытка обсуждать предикат в отсутствии предиката.

V>>В общем, повторюсь, пошаговость можно получить только явно эмулируя ФП на императивном вычислителе

A>В частности, эмулируя if.

Боюсь, "пошаговость" на одном только if не даст той наглядности, о которой исходно была речь.
А так-то да, ФП эмулируется на регистровых современных архитектурах. А даже предложенная для ФП data-flow архитектура вычислителя, упс... тоже упорядочивает вычисления на if.

Основополагающим понятием потоковых (Dataflow) вычислений является принцип готовности к выполнению (ГКВ) операции по условию готовности всех необходимых для выполнения этой операции операндов. Операнд считается «готовым», если соответствующим этому операнду ячейкам памяти присвоено значение (вычислено ранее или константо-присвоено).


V>> Причем, чтобы сохранить соответствие исходника и происходящему в процессе трассировки, пошагово трассировать нужно непреобразованный ФП-исходник.

A>Трассировка принадлежит к неязыковым средствам, обеспечивающим доступ к императивному вычислителю, эмулирующему ФП. Ее наличие не влияет на семантику языковых элементов, в частности оператора ветвления.

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


V>>Ну или в некоторых мультипарадигменных ФП-языках, которые не являются полностью чистыми (типа Хаскеля), можно получать пошаговость, т.е. явно заданный порядок вычислений, на специальных императивных механизмах, типа монады IO.

A>Функционального программирования не существует?

Agda2 пойдет? ))
Чистое ФП пригодно только для анализа св-в комбинации/отношений ф-ий... напр., для док-ва теорем (если исходные прикладные отношения закодировать в виде ф-ых зависимостей).

Видишь ли... ФП не самодостаточно ввиду своей ограниченности, поэтому практически-применимые фП-языки на самом деле мультипарадигменные. Это надо хотя бы помнить. То бишь, возвращаясь к теме обсуждения: изучая практически-применимые ФП-языки никуда не деться от императива. Так зачем же изучать всё сразу?
Re[31]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 11:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Проблемы не в конкретном вузе, а в абитуриентах которые идут в ИТ-специальности в странах бывшего СССР не все в порядке, из них 90% знают математику крайне плохо, ансктолько плохо что делают массу ошибок в вычислениях.

S>>Идут-то ладно, как же они попадают в эти ВУЗ-ы? Ты все увиливаешь от ответов на тему экзаменов...

I>Очень просто — минимальная планка в вузах испокон веков на уровне где то середнячка из сельской школы.

так то сельские вузы
I>На примере(просто пример для иллюстрации), есть 50 бюджетных мест. Есть 100 желающих. Миниальный уровень — скажем, решение 3х задач уровня А в сборнике Сканави. 40 человек решает 4 задачи, 60 — 3.
I>Итого, 50 мест будет распределено таким образом — 40 из тех, кто решил 4 задачи и 10 кто осилил только 3. Еще сюда можно добавить льготы различные, например для сельских, взятки и разно непотребство, то картина получается не самая радужная.
Не знаю желающих устроиться на бюджетные места в ИТ. Может быть в сельской школе их достаточно. Картина там не радужная не от того что в вузах дают что-то не так, а от того что $500 там потолок. Вобщем если хочешь пообсуждать бюджетное обучение для бюджетных мест в техникумах, то давай без меня.

I>>>Представь себе, для этого не надо учиться в каждом из вузов по 5 лет. Из вузов бывшего СССР где есть ИТ специальности можно вообще разогнать 3/4 и это ничего не изменит

S>>Ну как же не изменит? Изменит. Тогда 3/4 не получат диплом о в/о, за которым собственно они туда пошли.

I>То есть, разница будет только в наличии диплома ? Спасибо, это и есть "ничего".

Для тебя это есть "ничего". А молодые люди за этим "ничего" тупят 5 лет в вузах

I>>>Посмотри что там за вузы были и какой там контигент.

S>>Нормальный контигент такой.

I>Не нормальный, в том то и дело.

Это ты такой исключительный

I>>>Азы программирования, а функциональщина задвигается специальным предметом, перед которым sicp является обязательным.

S>>С тем что это АЗЫ — я согласен. А с тем что это не функциональные азы — нет.

I>Этот сикп к слову уже давно не сикп. Смотри сам http://mit.edu/6.01/www/calendar.html

I>Там даже программуха так, побочный эффект, сразу начинают с роботов всяких, автоматов и все это на императивном питоне.
Ну и что что давно не сикп. Меня он интересует как положительный опыт обучения 600 человек в год 40 лет.
Re[101]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 11:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>При чем тоже самое и в россии и в любой из стран бывшего ссср.

S>>Ты все же ВУЗ-ы с техникумами не путай, даже если они и получили вывески университетов и академий.

I>Ты предлагаешь из списка вузов вычеркнуть часть, котоаря тебе неудобна, и оставшиеся рассматривать как вузы ?

я предлагаю не тащить в список вузов вчерашние профтехникумы.

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

ты говоришь о насыщении бюджетных ИТ вакансий тупарями со способностями, соответствующими потолку з/п. Мне эта тема не интересна.
Re[102]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 13:02
Оценка:
Здравствуйте, samius, Вы писали:

I>>Ты предлагаешь из списка вузов вычеркнуть часть, котоаря тебе неудобна, и оставшиеся рассматривать как вузы ?

S>я предлагаю не тащить в список вузов вчерашние профтехникумы.

Все гораздо хуже, нужно еще и позабирать аттестаты у тех, что опопсели.

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

S>ты говоришь о насыщении бюджетных ИТ вакансий тупарями со способностями, соответствующими потолку з/п. Мне эта тема не интересна.

Я говорю о том, что уже есть по факту.
Re[32]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 13:15
Оценка:
Здравствуйте, samius, Вы писали:

I>>Очень просто — минимальная планка в вузах испокон веков на уровне где то середнячка из сельской школы.

S>так то сельские вузы
I>>На примере(просто пример для иллюстрации), есть 50 бюджетных мест. Есть 100 желающих. Миниальный уровень — скажем, решение 3х задач уровня А в сборнике Сканави. 40 человек решает 4 задачи, 60 — 3.
I>>Итого, 50 мест будет распределено таким образом — 40 из тех, кто решил 4 задачи и 10 кто осилил только 3. Еще сюда можно добавить льготы различные, например для сельских, взятки и разно непотребство, то картина получается не самая радужная.
S>Не знаю желающих устроиться на бюджетные места в ИТ. Может быть в сельской школе их достаточно. Картина там не радужная не от того что в вузах дают что-то не так, а от того что $500 там потолок. Вобщем если хочешь пообсуждать бюджетное обучение для бюджетных мест в техникумах, то давай без меня.

Протри глаза, речь про поступление в вуз на бюджентные места.

I>>То есть, разница будет только в наличии диплома ? Спасибо, это и есть "ничего".

S>Для тебя это есть "ничего". А молодые люди за этим "ничего" тупят 5 лет в вузах

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

I>>Не нормальный, в том то и дело.

S>Это ты такой исключительный

Ну да, это я причина тому, что в мит учиться трудно

I>>Этот сикп к слову уже давно не сикп. Смотри сам http://mit.edu/6.01/www/calendar.html

I>>Там даже программуха так, побочный эффект, сразу начинают с роботов всяких, автоматов и все это на императивном питоне.
S>Ну и что что давно не сикп. Меня он интересует как положительный опыт обучения 600 человек в год 40 лет.

Там не просто 600 любых, а 600 которые прошли сумасшедший конкурс.
Re[104]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 13:16
Оценка:
Здравствуйте, samius, Вы писали:

I>>>>Это обычный провициальный вуз, про который я и говорю. Ядерный центр это и близкно не ИТ, так что расслабсь, все в порядке.

S>>>А я и не говорил что он близко ИТ. Зато там есть электротехника и всегда найдется полпотока тупых

I>>Если не ИТ, то для чего ты пример приводил, для весу ?


S>По ключевым совпадениям. Ну а потом, не думаешь ли ты что в ИТ работают только те кто закончил ИТ?


Думаешь это влияет на уровень подготовки выпускниов конкретного вуза ? А ты, непростой
Re[33]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 13:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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

1 к 2м — это конкурс местячкового вуза. Сливки туда уже не пойдут, т.к. уехали на большую землю. Конкурируют там за места троешники, сельские и выпускники техникумов.

S>>Для тебя это есть "ничего". А молодые люди за этим "ничего" тупят 5 лет в вузах


I>В отрасли ничего не изменится. Вообще ничего, ибо эта самая отрасль уже давно потребляет необученый контингент. Все просто — большинство вузов дает вобщем уровень подготовки который равносилен полугодичному интенсивному ликбезу.

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

I>>>Не нормальный, в том то и дело.

S>>Это ты такой исключительный

I>Ну да, это я причина тому, что в мит учиться трудно

Мне тоже было учиться трудно. А учился я далеко от мита.

S>>Ну и что что давно не сикп. Меня он интересует как положительный опыт обучения 600 человек в год 40 лет.


I>Там не просто 600 любых, а 600 которые прошли сумасшедший конкурс.

Для тех кто в состоянии платить за обучение не такой он и сумасшедший.
Re[32]: Императивное программирование
От: vdimas Россия  
Дата: 15.10.12 14:11
Оценка:
Здравствуйте, samius, Вы писали:

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

S>
S>f x = a*x + b
S>

S>тоже не_обычная функция. Сначала будет обязательно вычислено умножение и лишь потом сложение

OMG, см. выделенное.
(ты умудрился придумать ф-ию с одним аргментом.)

Для того, чтобы аналогия не хромала, надо так:
f x a b = a*x + b

Вот теперь докажи, что a и x вычисляются раньше b.
Re[32]: Императивное программирование
От: vdimas Россия  
Дата: 15.10.12 14:43
Оценка:
Здравствуйте, artelk, Вы писали:


A>>>Прекрасно, а чем if не функция?

V>>Тем, что это не обычная ф-ия, у ней же аргументы вычисляются в жестко заданном порядке: сначала обязательно будет вычислен предикат. В общем, даже если дело происходит на ленивом механизме, то будет два обязательных правила:
V>>1. Предикат будет вычислен раньше успешной ветки.
V>>2. Если предикат вычислен, то успешная ветка тоже обязательно будет вычислена.
A>Тебе уже показали, что ничего обязательного в этих правилах нет.

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


A>>>Ну тогда и "необходимо иметь уже вычисленный аргумент-предикат" так же попахивает непониманием. Нет никакой такой необходимости после подстановки символов.

V>>Это только если предикат оперирует compile-time данными и может быть вычислен в compile-time.
A>Нет, не только.

Опять непонимание. Если if никуда не делся после подстановки всех символов, то его аргументы будут вычисляться в указанном мною порядке.


V>>Боюсь, "пошаговость" на одном только if не даст той наглядности, о которой исходно была речь.

V>>А так-то да, ФП эмулируется на регистровых современных архитектурах. А даже предложенная для ФП data-flow архитектура вычислителя, упс... тоже упорядочивает вычисления на if.
V>>

V>>Основополагающим понятием потоковых (Dataflow) вычислений является принцип готовности к выполнению (ГКВ) операции по условию готовности всех необходимых для выполнения этой операции операндов. Операнд считается «готовым», если соответствующим этому операнду ячейкам памяти присвоено значение (вычислено ранее или константо-присвоено).

A>Детали реализации императивного вычислителя не имеют никакого отношения к вопросу о семантике оператора ветвления в ФП.

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


V>>Итого, сначала необходимо изучить императив, чтобы понимать происходящее в процессе эмуляции ФП.

A>Чтобы понимать происходящее в процессе эмуляции — да. Чтобы понимать ФП — нет.

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

A>>>Функционального программирования не существует?

V>>Agda2 пойдет? ))
A>В Agda2 нет паттерн-матчинга?

В чистых Agda2-программах, которые пишут исключительно как proof-assistance, никакой код не выполняется. То бишь, рассуждать о том, что выполнится раньше — нелепо. Там целью является успешная компиляция. А если запускают на выполнение, то ничем от Хаскеля происходящее не отличается: http://progopedia.com/implementation/agda-2/
Re[34]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 15.10.12 14:46
Оценка:
Здравствуйте, samius, Вы писали:

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

S>1 к 2м — это конкурс местячкового вуза. Сливки туда уже не пойдут, т.к. уехали на большую землю. Конкурируют там за места троешники, сельские и выпускники техникумов.

Про кризис в образовании ты понятно ничего не слышал

I>>В отрасли ничего не изменится. Вообще ничего, ибо эта самая отрасль уже давно потребляет необученый контингент. Все просто — большинство вузов дает вобщем уровень подготовки который равносилен полугодичному интенсивному ликбезу.

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

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

I>>Ну да, это я причина тому, что в мит учиться трудно

S>Мне тоже было учиться трудно. А учился я далеко от мита.

Всего навсего в мит тебе было бы намного труднее.

I>>Там не просто 600 любых, а 600 которые прошли сумасшедший конкурс.

S>Для тех кто в состоянии платить за обучение не такой он и сумасшедший.

Цены на обучение там ни разу не баснословные по американским меркам. Мит, стенфорд и подобные вузы считаются самыми лучшими вузами во всем мире. Соответственно и контингент там гораздо сильнее.
Re[33]: Императивное программирование
От: artelk  
Дата: 15.10.12 14:57
Оценка:
Здравствуйте, vdimas, Вы писали:

V>
V>f x a b = a*x + b
V>

V>Вот теперь докажи, что a и x вычисляются раньше b.

Покажи реализацию оператора (+) для типа Int.
Тип Int можно определить, например, так:
  data Int = 0 | 1 | -1 | 2 | -2 | ...

или на основе списка цифр.
Re[33]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 15:58
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


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

S>>
S>>f x = a*x + b
S>>

S>>тоже не_обычная функция. Сначала будет обязательно вычислено умножение и лишь потом сложение

V>OMG, см. выделенное.

V>(ты умудрился придумать ф-ию с одним аргментом.)
Я же помню твой посыл

А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе.

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


V>Для того, чтобы аналогия не хромала, надо так:

V>
V>f x a b = a*x + b
V>

V>Вот теперь докажи, что a и x вычисляются раньше b.
Лучше ты доказывай что пошаговости в ФП быть не может.
Re[35]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 15.10.12 16:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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

S>>1 к 2м — это конкурс местячкового вуза. Сливки туда уже не пойдут, т.к. уехали на большую землю. Конкурируют там за места троешники, сельские и выпускники техникумов.

I>Про кризис в образовании ты понятно ничего не слышал

Слышал. Образование дисредитировано тем что дипломы о в/о раздают в ПТУ без каких либо требований к выпускаемым специалистам.

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


I>Очень просто разрешается — нужно сужать специализацию. Вузы вобщем то и идут этим путем. Вместо универсального "программист" появляются разработчики, тестировщики, безопасники, админы и тд и тд.

Первый раз слышу что бы админов выпускали ВУЗ-ы. Ты все-же про ПТУ.

I>>>Ну да, это я причина тому, что в мит учиться трудно

S>>Мне тоже было учиться трудно. А учился я далеко от мита.

I>Всего навсего в мит тебе было бы намного труднее.

Возможно, но я не считаю программу МИТ-а непостижимой. Для среднего ПТУ-шника — конечно. Но я не о них, а ты о них.

I>Цены на обучение там ни разу не баснословные по американским меркам. Мит, стенфорд и подобные вузы считаются самыми лучшими вузами во всем мире. Соответственно и контингент там гораздо сильнее.

Чем в ПТУ на постсоветском пространстве? Очевидно.
Re[36]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 08:20
Оценка:
Здравствуйте, samius, Вы писали:

I>>Про кризис в образовании ты понятно ничего не слышал

S>Слышал. Образование дисредитировано тем что дипломы о в/о раздают в ПТУ без каких либо требований к выпускаемым специалистам.

Вообще говоря проблемы растут ажно с самой школы.

I>>Очень просто разрешается — нужно сужать специализацию. Вузы вобщем то и идут этим путем. Вместо универсального "программист" появляются разработчики, тестировщики, безопасники, админы и тд и тд.

S>Первый раз слышу что бы админов выпускали ВУЗ-ы. Ты все-же про ПТУ.

И давно у вас в россии инженеров выпускают ПТУ ?

I>>Всего навсего в мит тебе было бы намного труднее.

S>Возможно, но я не считаю программу МИТ-а непостижимой. Для среднего ПТУ-шника — конечно. Но я не о них, а ты о них.

Теоретически все что может один человек, может и другой. Например слетать в космос или выжать штангу в 400кг весом. На практике все гораздо прозаичнее.

I>>Цены на обучение там ни разу не баснословные по американским меркам. Мит, стенфорд и подобные вузы считаются самыми лучшими вузами во всем мире. Соответственно и контингент там гораздо сильнее.

S>Чем в ПТУ на постсоветском пространстве? Очевидно.

И давно у вас в россии инженеров выпускают ПТУ ?
Re[34]: Императивное программирование
От: vdimas Россия  
Дата: 16.10.12 08:41
Оценка:
Здравствуйте, artelk, Вы писали:

V>>
V>>f x a b = a*x + b
V>>

V>>Вот теперь докажи, что a и x вычисляются раньше b.

A>Покажи реализацию оператора (+) для типа Int.

A>Тип Int можно определить, например, так:
A>
A>  data Int = 0 | 1 | -1 | 2 | -2 | ...
A>

A>или на основе списка цифр.

Задавай вопросы прямо. Сложение — это бинарная (минимум) чистая ф-ия, абсолютно неважно в каком порядке будут вычислены ее аргументы. Что именно ты хотел услышать?
Re[37]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 08:41
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Про кризис в образовании ты понятно ничего не слышал

S>>Слышал. Образование дисредитировано тем что дипломы о в/о раздают в ПТУ без каких либо требований к выпускаемым специалистам.

I>Вообще говоря проблемы растут ажно с самой школы.

О чем речь, если в ваших школах 90% выпускников не умеет подставлять в формулы.

S>>Первый раз слышу что бы админов выпускали ВУЗ-ы. Ты все-же про ПТУ.


I>И давно у вас в россии инженеров выпускают ПТУ ?

У нас в России по части инженеров не уверен, а вот админов выпускают даже школы.

S>>Возможно, но я не считаю программу МИТ-а непостижимой. Для среднего ПТУ-шника — конечно. Но я не о них, а ты о них.


I>Теоретически все что может один человек, может и другой. Например слетать в космос или выжать штангу в 400кг весом. На практике все гораздо прозаичнее.

У нас в России другая практика.
Re[34]: Императивное программирование
От: vdimas Россия  
Дата: 16.10.12 09:00
Оценка:
Здравствуйте, artelk, Вы писали:

V>>Если if никуда не делся после подстановки всех символов, то его аргументы будут вычисляться в указанном мною порядке.

A>Но результат не зависит от порядка вычисления аргументов, что дает нам основание утверждать, что операция ветвления не является "пошаговой по свой природе".

Ты решил зайти на второй круг? )))
А как насчет вычислимости ложной ветки? Так и не понял примера с факториалом? Ну хорошо... а как насчет корня из отрицательного числа? А как насчет деления на 0? Ведь реакция вычислителя в процессе вычисления должна сильно разниться для правильной и ложной веток в твоей умозрительной системе.
Re[34]: Императивное программирование
От: vdimas Россия  
Дата: 16.10.12 09:01
Оценка:
Здравствуйте, samius, Вы писали:

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

S>>>
S>>>f x = a*x + b
S>>>

S>>>тоже не_обычная функция. Сначала будет обязательно вычислено умножение и лишь потом сложение

V>>OMG, см. выделенное.

V>>(ты умудрился придумать ф-ию с одним аргментом.)
S>Я же помню твой посыл
S>

S>А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе.

S>И показываю тебе пошаговость с одним аргументом. См. выделенное.

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

То бишь все операнды a*x+b вычисляются аппаратным блоком за один такт. Курить схемы ускоренного сложения и параллельного умножения. Там в конце один "широкий" сумматор на все частичные произведения и на эту накопительную сумму, в кач-ве которой у тебя идет переменная b.


V>>Для того, чтобы аналогия не хромала, надо так:

V>>
V>>f x a b = a*x + b
V>>

V>>Вот теперь докажи, что a и x вычисляются раньше b.
S>Лучше ты доказывай что пошаговости в ФП быть не может.

Я уже всё показал. Извольте возражения по-существу или контрпримеры. Как именно возникает пошаговость на IO, я тоже рядом показал.
Re[30]: Императивное программирование
От: vdimas Россия  
Дата: 16.10.12 09:40
Оценка:
Здравствуйте, artelk, Вы писали:

A>>>Естественно, хаки не рассматриваем.

V>>Увы, хаки тебе будут нужны для реального эксперимента. В чем заключается хак — уже написал.
A>Ты уж сначала определись, хаков не может быть в чистом ФП или условного оператора?

Угу, классическое "кто здесь?"
Покажи место, где кто-то сомневался в том, что не может быть хаков? Они есть, пользуйся. На худой конец — исходники компилятора доступны, зашей туда оператор отладочной печати, награди его типом без ->IO. И убедись, наконец.

A>>>А что мешает первому случаю быть синтаксическим сахаром для второго? Невычисление одной из веток будет всего лишь оптимизацией.

V>>Да в принципе, если первое выражение нахождения знака числа будет унутре сделано через ветвление, то ничего не мешает. Будет то же самое безо-всяких оптимизаций. Просто бывают такие инструкции, которые некоторых процов, которые умеют помещать в АЛУ знак числа без ветвления.
A>Ну.. ты понял, вобщем.

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

V>>А в общем случае наверно мешает тот момент, что компиляторы пока плохо различают одну и ту же семантику, выраженную разными способами. Ес-но, как только компиляторы научаться полностью понимать "семантику" происходящего, то это станет не принципиально. Дык, это станет непринципиально для императива и ФП в равной мере, то бишь, опять у ФП никаких преимуществ.

V>>Кароч, я тут уже говорил как-то, что со временем ФП будет не особо нужно, бо компиляторы будут сами находить скрытые ошибки императиве, как это сегодня делает тулзина Valgrind, например. Смотри в суть вещей — ФП языки нужны сугубо как костыль для тупых компиляторов образца до начала ~2000-х годов. После этого наступили такие времена, что ведущие компиляторы с того же С++ стали частично суперкомпиляторами и "понимают" намного больше семантики (совершая в итоге намного больше преобразований) чем все компиляторы со всех ФП-языков вместе взятые.

A>Какой кошмар. Готовишься к конкурсу на звание "Самый альтернативно мыслящий"?! Мой голос за тебя!


Дык, курить современную суперкомпиляцию. Увы, чистое ФП сосёт, не нагибаясь... как раз из-за того, что возможности той самой бета-редукции, которой одни фанаты уже задолбали, а другие (якобы ФП-программисты) так и не понимают толком, оказались небольшими из-за... упс!!! ограничений, накладываемых системой типов. Настоящая суперкомпиляция появляется уже после разложения результатов подобной оптимизации в регистровом базисе, то бишь после удаления информации о типах. Просто современные тру-ФП-программеры застряли на уровне конца 80-х начала 90-х и уперлись там же.
Вернее так, тот интерес, который потихоньку просыпался в начале 90-х, докатился, наконец, до "широких масс" по причине банального увеличения памяти и быстродействия процов, а не по причине того, что ФП наконец-то научился использовать "весь свой потенциал, который даёт чистота вычислений" (С). Так-то до этого без слез на тру-ФП смотреть было невозможно. Да и сейчас тоже. Да и Хаскель как-то всё больше движется в сторону заимствований то у ООП, то у императива со всякими своими многопоточными расширениями. Да и ссылочная прозрачность (тот самый целевой фактор), как выяснилось, не противоречит императиву и вовсе не требует иммутабельности. Ууупс??? )))


A>>>Производительность ветвлений на современной аппаратуре не имеет никакого отношения к вопросу о семантике оператора ветвления в ФП.

V>>Да ради бога. Я лишь одобрил попытку убежать от if.
A>Попытки убежать от if с целью улучшения производительности, в данном конкретном случае, не было. Пример приводился с другой целью.

Что ты хотел показать, понятно и школьнику. Я лишь растягиваю удовольствие, жду пока ты поймешь. Просто твою "другую цель" даже обсуждать не имело смысла, ведь у тебя выражение (x>0) никак не может быть вычисленно позже последующей формулы. Я уже молчу о другом твоём капитальном залёте, который ни ты, ни плюсующие тебе уже 3-й пост не видите.

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

A>Ну.. ты понял, вобщем.

Я-то понял и уже даже дал подсказки, а ты еще нет и даришь мне уже который пост подряд маленький заслуженный фан.
Не раскроешь, случаем, особенности своего мышления?... которые позволяют тебе пытаться рассуждать насчет твоего примера ф-ии abs(x), расписанном на if, об упорядоченности вычисления операндов? Так и не понял подсказку abs(x)? Операндов-то сколько, горемыка? Там же все три операнда ф-ии if (будь он на if сделано) — один и тот же x. Это залёт, курсант.
Re[35]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 09:55
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>

S>>А в ФП не может быть никакой пошаговости кроме случая эмуляции ФП на императивном вычислителе.

S>>И показываю тебе пошаговость с одним аргументом. См. выделенное.

V>Не показываешь. Если нет переменной для промежуточного результата a*b, то нет возможности наблюдения результата таких промежуточных вычислений.

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

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


V>То бишь все операнды a*x+b вычисляются аппаратным блоком за один такт. Курить схемы ускоренного сложения и параллельного умножения. Там в конце один "широкий" сумматор на все частичные произведения и на эту накопительную сумму, в кач-ве которой у тебя идет переменная b.

О, и на основе частного случая ты опровергаешь наличие такого шага. А что если я тебе дам выражение с приоритетами, для которого нет соответствующего проца, считающего его за такт? Соберешь такой проц?

S>>Лучше ты доказывай что пошаговости в ФП быть не может.


V>Я уже всё показал. Извольте возражения по-существу или контрпримеры. Как именно возникает пошаговость на IO, я тоже рядом показал.

Я те поражаюсь вообще. Выдумываешь какой-то мутный посыл про ФП (что не может быть пошаговости), находишь в ФП же некий "шаг" в виде if-а, и тем самым доказываешь что ФП не существует или что оно произошло от СП.
Жги еще.
Re[38]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 10:10
Оценка:
Здравствуйте, samius, Вы писали:

I>>Вообще говоря проблемы растут ажно с самой школы.

S>О чем речь, если в ваших школах 90% выпускников не умеет подставлять в формулы.

В ваших школах ничуть не лучше.

S>>>Первый раз слышу что бы админов выпускали ВУЗ-ы. Ты все-же про ПТУ.


I>>И давно у вас в россии инженеров выпускают ПТУ ?

S>У нас в России по части инженеров не уверен, а вот админов выпускают даже школы.

Админ это инженер, по диплому обычно инженер-системотехник. Давно у вас таких в ПТУ готовят ?

I>>Теоретически все что может один человек, может и другой. Например слетать в космос или выжать штангу в 400кг весом. На практике все гораздо прозаичнее.

S>У нас в России другая практика.

Все космонавты что ли ?
Re[39]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 10:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Вообще говоря проблемы растут ажно с самой школы.

S>>О чем речь, если в ваших школах 90% выпускников не умеет подставлять в формулы.

I>В ваших школах ничуть не лучше.

Разве что в школах для альтернативно одаренных, вы походу из них специалистов набираете...

I>>>И давно у вас в россии инженеров выпускают ПТУ ?

S>>У нас в России по части инженеров не уверен, а вот админов выпускают даже школы.

I>Админ это инженер, по диплому обычно инженер-системотехник. Давно у вас таких в ПТУ готовят ?

У нас админы самородки.

S>>У нас в России другая практика.


I>Все космонавты что ли ?

Не все, но побольше чем у вас.
Re[40]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 10:54
Оценка:
Здравствуйте, samius, Вы писали:

I>>В ваших школах ничуть не лучше.

S>Разве что в школах для альтернативно одаренных, вы походу из них специалистов набираете...

Из последнего — Академия ФСБ России факультет "Информационная безопасность"

"альтернативно одаренных" говоришь ? Ну-ну
Re[41]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 10:59
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>В ваших школах ничуть не лучше.

S>>Разве что в школах для альтернативно одаренных, вы походу из них специалистов набираете...

I>Из последнего — Академия ФСБ России факультет "Информационная безопасность"


I>"альтернативно одаренных" говоришь ? Ну-ну

Туда как раз таких и берут
Re[40]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 10:59
Оценка:
Здравствуйте, samius, Вы писали:

I>>Все космонавты что ли ?

S>Не все, но побольше чем у вас.

Да, заметно
Re[41]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 11:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Все космонавты что ли ?

S>>Не все, но побольше чем у вас.

I>Да, заметно

I>
Заметно что у тебя с юмором проблемы
Re[42]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 11:03
Оценка:
Здравствуйте, samius, Вы писали:

I>>Да, заметно

I>>
S>Заметно что у тебя с юмором проблемы

Валяй, разрешаю обсуждать мою личность в течении десяти постов
Re[43]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 11:08
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:

I>Валяй, разрешаю обсуждать мою личность в течении десяти постов
Много чести, да и разрешение мне твое не нужно.
Re[42]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 11:58
Оценка:
Здравствуйте, samius, Вы писали:

I>>Из последнего — Академия ФСБ России факультет "Информационная безопасность"


I>>"альтернативно одаренных" говоришь ? Ну-ну

S>Туда как раз таких и берут

Итого, когда я говорю о вузе скажем на примере этой академии(есть и другие), тебе не нравится и ты резко не согласен, при этом сам ты считаешь такой вуз навроде ПТУ
Вобщем, я думаю тебе стоит поискать аргументы кроме псевдопатриотизма и перехода на личности
Re[33]: Императивное программирование
От: artelk  
Дата: 16.10.12 14:44
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Осталось убедительно показать, что происходящее в процессе эмуляции прямо по исходнику ФП-программы хоть чем-то отличается от твоего "понимания" ФП. программист-то в процессе написания рпограммы как-то трекает в голове, как она должна работать, не?

Систему математических уравнений ведь можно понять без знания о точном порядке в каком она будет вычисляться.
Вот программа на ФП, по сути, и представляет из себя систему уравнений.

V>В чистых Agda2-программах, которые пишут исключительно как proof-assistance, никакой код не выполняется. То бишь, рассуждать о том, что выполнится раньше — нелепо. Там целью является успешная компиляция. А если запускают на выполнение, то ничем от Хаскеля происходящее не отличается: http://progopedia.com/implementation/agda-2/

Программа является написанной на чистом функциональном языке до тех пор пока ее не запускают?? Оригинально.
Re[43]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 14:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Из последнего — Академия ФСБ России факультет "Информационная безопасность"


I>>>"альтернативно одаренных" говоришь ? Ну-ну

S>>Туда как раз таких и берут

I>Итого, когда я говорю о вузе скажем на примере этой академии(есть и другие), тебе не нравится и ты резко не согласен, при этом сам ты считаешь такой вуз навроде ПТУ

С чем я не согласен? Я подтверждаю что там альтернативно одаренные люди. Ты бы еще высшую школу милиции привел...
У меня в ВУЗ-е была кафедра безопасников. Там учились
а) платники, не прошедшие по конкурсу на бюджетные места (совсем не прошедшие)
б) служивые без конкурса
в) вылетевшие с бюджетных мест, но имеющие деньги на обучение + проживание, т.к. общагу безопасникам не давали.
Самое громкое достижение студентов с этой кафедры на моей памяти — многометровая веревка с нанизанными одна к другой пробками от водки, привезенная с "картошки". Точнее, их вклад там был наиболее значим.
Оттуда не вышибали, потому все, кто имел деньги на обучение, закончили благополучно. Уж точно программирования в их программе не было больше чем у бюджетников, а уж "необязательность" посещения занятий и экзаменов расставила все по местам. И не только по программированию.
А что ты ожидаешь от академии ФСБ — для меня вообще загадка.

I>Вобщем, я думаю тебе стоит поискать аргументы кроме псевдопатриотизма и перехода на личности

Твое утверждение про 90%, вот и приводи аргументы. Только не надо про академию ФСБ. Они там вряд ли формулами пользуются. У них другие методы.
Да и выборка опять нерепрезентативна. У кого все не сильно хреново с математикой/физикой/химией и т.п. вряд ли туда пойдут сами.
А когда туда набирают извне, то там совершенно другие критерии отбора, чем тебе хотелось бы.
Я не говорю что там нет гениев. Есть, конечно. Но даже хорошисты по учебе вряд ли станут искать работу, т.к. будут пристроены куда надо. Вобщем, подозреваю что к тебе попал настолько альтернативно одареннейший из альтернативно одаренных, что его даже к своим не пристроили. А может это агент без прикрытия?
Re[35]: Императивное программирование
От: artelk  
Дата: 16.10.12 14:51
Оценка:
Здравствуйте, vdimas, Вы писали:

A>>Покажи реализацию оператора (+) для типа Int.

A>>Тип Int можно определить, например, так:
A>>
A>>  data Int = 0 | 1 | -1 | 2 | -2 | ...
A>>

A>>или на основе списка цифр.

V>Задавай вопросы прямо. Сложение — это бинарная (минимум) чистая ф-ия, абсолютно неважно в каком порядке будут вычислены ее аргументы.

Чистая функция? Отлично. А ее можно реализовать на чистом функциональном языке? Или может она должна быть априорно дана "свыше" вместе с постулированием ее чистоты?

V>Что именно ты хотел услышать?

Хотел увидеть реализацию.
Re[44]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.10.12 15:18
Оценка:
Здравствуйте, samius, Вы писали:

I>>Итого, когда я говорю о вузе скажем на примере этой академии(есть и другие), тебе не нравится и ты резко не согласен, при этом сам ты считаешь такой вуз навроде ПТУ

S>С чем я не согласен? Я подтверждаю что там альтернативно одаренные люди. Ты бы еще высшую школу милиции привел...

Ну то есть, тебе удобно считать ВУЗ как ПТУ, но при этом ты резко не согласен, что такой ВУЗ я считаю дохленьким.

S>А что ты ожидаешь от академии ФСБ — для меня вообще загадка.


Ничего не ожидаю. Думаешь эта академия сильно отличается от вузов навроде рязанского радиотехнического или оренбургский гусударственный университет ?
Это ж тоже ПТУ по твоей классификации. Люди которые попадали к нам оттуда еле еле учились, хотя там были чуть не отличники.
Собственно на собеседованиях я ничего нового не увидел

I>>Вобщем, я думаю тебе стоит поискать аргументы кроме псевдопатриотизма и перехода на личности

S>Твое утверждение про 90%, вот и приводи аргументы. Только не надо про академию ФСБ. Они там вряд ли формулами пользуются. У них другие методы.

"другие методы" А программируют они чисто ради хобби, ага

S>Да и выборка опять нерепрезентативна. У кого все не сильно хреново с математикой/физикой/химией и т.п. вряд ли туда пойдут сами.


Это не важно. Количество сильных вузов которые ты и называешь вузами (а все остальные — ПТУ, навроде академии ФСБ) вообще говоря мало. Выпускники этих вузов не могут покрыть спрос на специалистов, то есть, вообще никак.
Re[45]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 16.10.12 15:35
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Ну то есть, тебе удобно считать ВУЗ как ПТУ, но при этом ты резко не согласен, что такой ВУЗ я считаю дохленьким.

я не понял что ты его считаешь дохленьким. Я думал что твой посыл в том, что аж из такого крутого ВУЗ-а, да такие дохлые спецы...

S>>А что ты ожидаешь от академии ФСБ — для меня вообще загадка.


I>Ничего не ожидаю. Думаешь эта академия сильно отличается от вузов навроде рязанского радиотехнического или оренбургский гусударственный университет ?

I>Это ж тоже ПТУ по твоей классификации. Люди которые попадали к нам оттуда еле еле учились, хотя там были чуть не отличники.
Да они там были отличниками потому что с них там ничего не спрашивали. А значит ПТУ по моей классификации.

I>Собственно на собеседованиях я ничего нового не увидел


I>"другие методы" А программируют они чисто ради хобби, ага

Их там чо, еще и программировать учили?

I>Это не важно. Количество сильных вузов которые ты и называешь вузами (а все остальные — ПТУ, навроде академии ФСБ) вообще говоря мало. Выпускники этих вузов не могут покрыть спрос на специалистов, то есть, вообще никак.

А что, выпускники должны что-то покрывать? Мне вообще говоря, это не очевидно. Руководителям ведущих ВУЗ-ов планеты — тоже. Если тебе нужна дешевая рабсила — это проблемы твои или твоей конторы. Нужна качественная сила — плати бабки и хорошо фильтруй. Никакого покрытия никто тебе не должен, пока ты не министр образования.
Re[31]: Императивное программирование
От: artelk  
Дата: 16.10.12 16:16
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Что ты хотел показать, понятно и школьнику. Я лишь растягиваю удовольствие, жду пока ты поймешь.

Эх, тоже жду... Но начинаю склоняться к мысли, что не во мне причина, почему я не могу понять...
V>Просто твою "другую цель" даже обсуждать не имело смысла, ведь у тебя выражение (x>0) никак не может быть вычисленно позже последующей формулы. Я уже молчу о другом твоём капитальном залёте, который ни ты, ни плюсующие тебе уже 3-й пост не видите.
заинтриговал

V>Я-то понял и уже даже дал подсказки, а ты еще нет и даришь мне уже который пост подряд маленький заслуженный фан.

V>Не раскроешь, случаем, особенности своего мышления?... которые позволяют тебе пытаться рассуждать насчет твоего примера ф-ии abs(x), расписанном на if, об упорядоченности вычисления операндов? Так и не понял подсказку abs(x)? Операндов-то сколько, горемыка? Там же все три операнда ф-ии if (будь он на if сделано) — один и тот же x. Это залёт, курсант.
Очень интересно. Т.е. если в качестве предиката было бы (x>1), то второй пример потерял бы свою функциональную чистоту?
Re[36]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 08:15
Оценка:
Здравствуйте, artelk, Вы писали:

V>>А как насчет вычислимости ложной ветки? Так и не понял примера с факториалом?

A>
A>uint fact(uint arg) {
A>  if(x < 2)
A>    return 1;
A>  else
A>    return arg * fact(arg - 1);
A>}
A>

A>Тут выражение в первой ветке можно вычислить до предиката, а можно и после.

В первой ветке константа, там нечего вычислять. Вторая гораздо интереснее.

V>>Ну хорошо... а как насчет корня из отрицательного числа? А как насчет деления на 0? Ведь реакция вычислителя в процессе вычисления должна сильно разниться для правильной и ложной веток в твоей умозрительной системе.

A>"Значением" ветки будет (_|_).

К сожалению, это унылый хак системы типов, нарушающий всякую чистоту ФП. При таком раскладе чистое ФП не существует, ты прав. )))

Кароч, возвращаемое значение ф-ии должно быть типизированным или никаким. То бишь либо ф-ия вычисляется, либо должна инициироваться исключительная ситуация. Либо необходимо вводить ограничение в язык, чтобы все ф-ии могли возвращать только такой тип:
data ResultOrError x = Result x | Error ErrorInfo


A>Если потом, после вычисления предиката, будет выбрана вторая ветка, значение всего выражения будет определяться ей.


ОК, даже если предыдущий механизм ResultOrError компилятор добавит сам, как часть некоего сценария "отложенной" генерации исключительных ситуаций, то бесконечное зацикливание на ложной ветке вычисления факториала не сразу-то и понятно как остановить. Тут только начни рассуждать в эту область и попробуй расширить на общий рекурсивный случай (а других и нет в ФП) и сразу станут видны все подводные камни. В общем, до тех пор, пока не избрели формальной методики для обсуждаемого, скорее прав я, чем вы.
Re[36]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 08:29
Оценка:
Здравствуйте, artelk, Вы писали:

A>>>Покажи реализацию оператора (+) для типа Int.

A>>>Тип Int можно определить, например, так:
A>>>
A>>>  data Int = 0 | 1 | -1 | 2 | -2 | ...
A>>>

A>>>или на основе списка цифр.

V>>Задавай вопросы прямо. Сложение — это бинарная (минимум) чистая ф-ия, абсолютно неважно в каком порядке будут вычислены ее аргументы.

A>Чистая функция? Отлично. А ее можно реализовать на чистом функциональном языке? Или может она должна быть априорно дана "свыше" вместе с постулированием ее чистоты?

Да любую ф-ию можно реализовать самому, ес-но. Но ты не можешь, как Мюнхгаузен, вытащить себя из боолта за волосы, — у тебя обязательно должен быть некий базис, с помощью которого ты опишешь производные комбинации.

V>>Что именно ты хотел услышать?

A>Хотел увидеть реализацию.

Давай базис.

==========
И да, если это намек на возможность задания перечислимого мн-ва через отношения абстрактных типов, типа как succ succ succ zero или прочая хрень из этой области, давай сразу переходи к своим выводам. Здесь базисом является отношение/отображение... Не сильно мощный базис, надо сказать... Уже с плавающей точкой некие проблемы (отдельная тема). Ну и опять же, ФП сразу не при чем. Системы типов императивных языков позволяют аналогичное. Например, С++ в может точно так же compile-time (привет Wolfhound с его непониманием, откуда в compile-time в С++ берутся зависимые типы).
Re[36]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 09:11
Оценка:
Здравствуйте, samius, Вы писали:

V>>Не показываешь. Если нет переменной для промежуточного результата a*b, то нет возможности наблюдения результата таких промежуточных вычислений.

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

Чем тебе аргументы ф-ий не переменные? Как насчет того, что в чистом ФП других переменных и быть-то не может?

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


V>>То бишь все операнды a*x+b вычисляются аппаратным блоком за один такт. Курить схемы ускоренного сложения и параллельного умножения. Там в конце один "широкий" сумматор на все частичные произведения и на эту накопительную сумму, в кач-ве которой у тебя идет переменная b.

S>О, и на основе частного случая ты опровергаешь наличие такого шага.

Да нет, не опровергаю. Но формулы действительно могут вычисляться в очень разном порядке. Дать тебе для разминки разложение разности квадратов? А произведение синусоид? А если вспомнить, что синусоиды считаются как ряды, то попробуй мне доказать, что в выражении sin(a)*sin(b) сначала будут вычислены операнды умножения, а не будет иметь место (после бета-редукции) оптимизированное вычисление ряда 0.5 * (cos(a+b)-cos(a-b)), где совпадающие элементы ряда будут вычислены лишь однажды?

S>А что если я тебе дам выражение с приоритетами, для которого нет соответствующего проца, считающего его за такт? Соберешь такой проц?


Очевидно, ты просто не понимаешь бета-редукцию или постоянно про нее забываешь. Боюсь, кроме как на ветвлении продемонстрировать приоритеты тебе будет сложно. Ведь в общем случае a и b — это выражения (ф-ии), которые, к тому же, вполне могут быть раскрыты "по-месту". Например, в примере с синусами это могли быть:
a(x)=0.5*(x^3-x)
b(x)=0.5*(x^3+x)
Заметь этом случае явно удобнее вычислить (a+b) и (a-b), и последующее разложение в ряд Тейлора даст кучу совпадающих степеных членов для обоих многочленов, последующее вычитание которых существенно сократит результирующий многочлен.


S>>>Лучше ты доказывай что пошаговости в ФП быть не может.


V>>Я уже всё показал. Извольте возражения по-существу или контрпримеры. Как именно возникает пошаговость на IO, я тоже рядом показал.

S>Я те поражаюсь вообще. Выдумываешь какой-то мутный посыл про ФП (что не может быть пошаговости), находишь в ФП же некий "шаг" в виде if-а, и тем самым доказываешь что ФП не существует или что оно произошло от СП.
S>Жги еще.

А ну да. Опять этот твой неоспоримый аргумент: "не может быть!".

Где "может быть" легко различимая поэтапность в ФП я уже показал. Почему происходящее в ветвлении в ФП и СП одинаково — тоже показал не раз. Даже с учетом ленивости. А если некие спекулятивные чистые вычисления ложных веток могут быть выполнены (как настаивают коллеги), то все-равно результат этих вычислений будет отброшен (ими же утверждается, хотя там есть тонкости, на которые они пока ответить не в состоянии). В любом случае, всегда можно считать, что этих вычислений не было — они были совершенны фантомом в параллельном пространстве и самоиспарились. А те вычисления, что нас интересуют — будут упорядоченны именно как я сказал. То бишь даже если во времени (в ФП во времени!!! гы-гы, вот уровень их рассуждений!), где-то будет вычислена положительная ветка раньше, то наблюдаемого результата этих вычислений все-равно не будет до тех пор, пока не будет вычислен предикат. Увы. Т.е. даже в случае автоматического распараллеливания, результат будет отложен как аргумент той самой ленивой ф-ии (в основном потоке вычислений), которая будет упорядочивать все параллельные вычисления. Упорядочивать будет, ес-но, по мере вычисления значений предикатов на ветвлении. Муахаха.. ))

====
Это я еще молчу о ветвлении на паттерн-матчинге, где в реальности сейчас происходит реинтерпретация памяти в общем случае, согласно значению дискриминанта алг-типа. Т.е. что именно в ложных ветках паттерн-матчинга можно вычислять в общем случае — это загадка из загадок.
Re[46]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.12 09:18
Оценка:
Здравствуйте, samius, Вы писали:

I>>Ну то есть, тебе удобно считать ВУЗ как ПТУ, но при этом ты резко не согласен, что такой ВУЗ я считаю дохленьким.

S>я не понял что ты его считаешь дохленьким. Я думал что твой посыл в том, что аж из такого крутого ВУЗ-а, да такие дохлые спецы...

Крутых вузов единицы. Ну может штук 10 по всей россии и потому выхлоп от них на общем фоне не виде.

I>>Ничего не ожидаю. Думаешь эта академия сильно отличается от вузов навроде рязанского радиотехнического или оренбургский гусударственный университет ?

I>>Это ж тоже ПТУ по твоей классификации. Люди которые попадали к нам оттуда еле еле учились, хотя там были чуть не отличники.
S>Да они там были отличниками потому что с них там ничего не спрашивали. А значит ПТУ по моей классификации.

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

I>>"другие методы" А программируют они чисто ради хобби, ага

S>Их там чо, еще и программировать учили?

Даже больше — после этого вуза еще и работают в ИТ.

I>>Это не важно. Количество сильных вузов которые ты и называешь вузами (а все остальные — ПТУ, навроде академии ФСБ) вообще говоря мало. Выпускники этих вузов не могут покрыть спрос на специалистов, то есть, вообще никак.

S>А что, выпускники должны что-то покрывать? Мне вообще говоря, это не очевидно. Руководителям ведущих ВУЗ-ов планеты — тоже.

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

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


Вот по таким принципам и строится все российское образование, результаты не удивляют.
Re[34]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 09:52
Оценка:
Здравствуйте, artelk, Вы писали:

V>>Осталось убедительно показать, что происходящее в процессе эмуляции прямо по исходнику ФП-программы хоть чем-то отличается от твоего "понимания" ФП. программист-то в процессе написания рпограммы как-то трекает в голове, как она должна работать, не?

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

В ФП речь может идти не об уравнениях, а о ручном решении уравнений. Не лучше, чем в императиве. Заметь, решения любых уравнений даются в любых учебниках/справочниках как вполне вполне пошаговые алгоритмы. То бишь, до фени даже в ФП или императиве это решение будет вопроизведено. Я потому и напоминаю периодически некоторым оторвавшимся от реальности, что современное ФП описывает решение ровно с той же степенью подробности, как императив. Отсюда мои потрунивания над использованием термина "декларативный" применительно к ФП.

A>Вот программа на ФП, по сути, и представляет из себя систему уравнений.


Садись, два. )))
Программа на ФП представляет из себя комбинацию ф-ий (односторонних отображений), больше ничего. Это программа не умеет совершать обратные отображения, необходимые для поиска решений, не умеет задавать аналитический вид этих отображений по обе стороны от =/</>/!=/etc. Любые отображения, задаваемые в ФП — это одностороння символьная подстановка и ничего более. Строгости ради можно считать, что никаких ф-ий нет, а есть символы, которыми заменили лямбды на этапе декомпозиции решения задачи.

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

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


V>>В чистых Agda2-программах, которые пишут исключительно как proof-assistance, никакой код не выполняется. То бишь, рассуждать о том, что выполнится раньше — нелепо. Там целью является успешная компиляция. А если запускают на выполнение, то ничем от Хаскеля происходящее не отличается: http://progopedia.com/implementation/agda-2/

A>Программа является написанной на чистом функциональном языке до тех пор пока ее не запускают?? Оригинально.

Блин, хотел же с тобой закругляться еще 3 дня назад, бо потеря времени...
Кароч, чтобы иметь возможность запустить программу на выполнение, она должна стать нечистой. Пройдись по ссылке.
Re[37]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 10:13
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


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


V>Чем тебе аргументы ф-ий не переменные? Как насчет того, что в чистом ФП других переменных и быть-то не может?

Какие еще переменные в чистом ФП?

V>>>То бишь все операнды a*x+b вычисляются аппаратным блоком за один такт. Курить схемы ускоренного сложения и параллельного умножения. Там в конце один "широкий" сумматор на все частичные произведения и на эту накопительную сумму, в кач-ве которой у тебя идет переменная b.

S>>О, и на основе частного случая ты опровергаешь наличие такого шага.

V>Да нет, не опровергаю. Но формулы действительно могут вычисляться в очень разном порядке. Дать тебе для разминки разложение разности квадратов? А произведение синусоид? А если вспомнить, что синусоиды считаются как ряды, то попробуй мне доказать, что в выражении sin(a)*sin(b) сначала будут вычислены операнды умножения, а не будет иметь место (после бета-редукции) оптимизированное вычисление ряда 0.5 * (cos(a+b)-cos(a-b)), где совпадающие элементы ряда будут вычислены лишь однажды?

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

S>>А что если я тебе дам выражение с приоритетами, для которого нет соответствующего проца, считающего его за такт? Соберешь такой проц?


V>Очевидно, ты просто не понимаешь бета-редукцию или постоянно про нее забываешь. Боюсь, кроме как на ветвлении продемонстрировать приоритеты тебе будет сложно. Ведь в общем случае a и b — это выражения (ф-ии), которые, к тому же, вполне могут быть раскрыты "по-месту". Например, в примере с синусами это могли быть:

V>a(x)=0.5*(x^3-x)
V>b(x)=0.5*(x^3+x)
V>Заметь этом случае явно удобнее вычислить (a+b) и (a-b), и последующее разложение в ряд Тейлора даст кучу совпадающих степеных членов для обоих многочленов, последующее вычитание которых существенно сократит результирующий многочлен.
И опять "вполне могут быть". А могут и не быть.


S>>Я те поражаюсь вообще. Выдумываешь какой-то мутный посыл про ФП (что не может быть пошаговости), находишь в ФП же некий "шаг" в виде if-а, и тем самым доказываешь что ФП не существует или что оно произошло от СП.

S>>Жги еще.

V>А ну да. Опять этот твой неоспоримый аргумент: "не может быть!".


V>Где "может быть" легко различимая поэтапность в ФП я уже показал.

Я не понимаю, почему тебя смущает поэтапность.

V>Почему происходящее в ветвлении в ФП и СП одинаково — тоже показал не раз. Даже с учетом ленивости.

Раз 10 тебя просил показать мне пользу императивного оператора if с чистыми ветками, пользу императивного цикла с чистым телом. Увы...
Могу еще попросить показать пользу от последовательности чистых стейтментов. Уверен что кончится тем же.

V>А если некие спекулятивные чистые вычисления ложных веток могут быть выполнены (как настаивают коллеги), то все-равно результат этих вычислений будет отброшен (ими же утверждается, хотя там есть тонкости, на которые они пока ответить не в состоянии). В любом случае, всегда можно считать, что этих вычислений не было — они были совершенны фантомом в параллельном пространстве и самоиспарились. А те вычисления, что нас интересуют — будут упорядоченны именно как я сказал. То бишь даже если во времени (в ФП во времени!!! гы-гы, вот уровень их рассуждений!), где-то будет вычислена положительная ветка раньше, то наблюдаемого результата этих вычислений все-равно не будет до тех пор, пока не будет вычислен предикат. Увы. Т.е. даже в случае автоматического распараллеливания, результат будет отложен как аргумент той самой ленивой ф-ии (в основном потоке вычислений), которая будет упорядочивать все параллельные вычисления. Упорядочивать будет, ес-но, по мере вычисления значений предикатов на ветвлении. Муахаха.. ))

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

V>====

V>Это я еще молчу о ветвлении на паттерн-матчинге, где в реальности сейчас происходит реинтерпретация памяти в общем случае, согласно значению дискриминанта алг-типа. Т.е. что именно в ложных ветках паттерн-матчинга можно вычислять в общем случае — это загадка из загадок.
Ты о нем молчишь потому как в базисе СП паттерн-матчинга нет и реализовать его на базисе СП не вопрос. Вот и молчи, т.к. никакой сути паттерн-матчинг не меняет. Вычисление жопы достижимо и на if-е.
Re[47]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 10:58
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>я не понял что ты его считаешь дохленьким. Я думал что твой посыл в том, что аж из такого крутого ВУЗ-а, да такие дохлые спецы...


I>Крутых вузов единицы. Ну может штук 10 по всей россии и потому выхлоп от них на общем фоне не виде.

Может ты мне покажешь пример страны с тысячей куртых вузов, которые дают ощутимый выхлоп на общем фоне?

S>>Да они там были отличниками потому что с них там ничего не спрашивали. А значит ПТУ по моей классификации.


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

Нет, не понимаю. Я понимаю, почему они не осилили программу ВУЗ-а. А почему не смогут осилить — не понимаю. Если хорошо прижмет — осилят и программу и сикп. Но раз это не требуется, то какой для них в этом смысл?

I>>>"другие методы" А программируют они чисто ради хобби, ага

S>>Их там чо, еще и программировать учили?

I>Даже больше — после этого вуза еще и работают в ИТ.

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

S>>А что, выпускники должны что-то покрывать? Мне вообще говоря, это не очевидно. Руководителям ведущих ВУЗ-ов планеты — тоже.


I>Выпускники ничего не должны. А вот для того, что бы работала система образования и в стране появлялись и распространялись высокие технологии, нужен выхлоп не только качественный, но и количественный. Очень легко сделать пару человек экстремально высокой квалификации. А вот сделать хотя бы тысячу но средней квалификации задача на порядки сложнее.

3/4 от тысячи средней квалификации получает корочки и уходит работать не по профилю. Остальные куда-то пристраиваются и поднимают квалификацию дальше. Никто не готовит пару экстремально высокой квалификации.
Вот как происходит. Допустим, некая серьезная контора, испытывающая недостаток в квалифицированных кадрах пытается встроиться в процесс обучения. Они направляют своего сотрудника в универ и оплачивают ему академические часы по такой ставке, что тот не теряет в зарплате. Этот сотрудник читает лекции, ведет практику и из выпускников отбирает пару продвинутых и делает им предложение об устройстве. Ничего экстемального в этом нет, просто пара подающих надежду и остальные. Эта пара в суперспециалистов превратится не раньше чем через 3-4 года работы.
Это я тебе привел пример обратной связи между потребителем спецов и поставщиком. Явление не сильно распространенное, но и не редкость. А вот изменение программы/стандартов образования — это под силу только на уровне министерств, причем, как правило эффект от этого негативный.

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


I>Вот по таким принципам и строится все российское образование, результаты не удивляют.

Я не понимаю, каких ты хочешь результатов? Обвала рынка ИТ специалистов? Вряд ли ты его получишь в длительной перспективе. Увеличится выпуск специалистов, их качество уменьшится, увеличится и их отток в другие области, в том числе торговлю телефонами/мебелью. И ты опять будешь переживать за индустрию.
Re[48]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.12 11:22
Оценка:
Здравствуйте, samius, Вы писали:

I>>Крутых вузов единицы. Ну может штук 10 по всей россии и потому выхлоп от них на общем фоне не виде.

S>Может ты мне покажешь пример страны с тысячей куртых вузов, которые дают ощутимый выхлоп на общем фоне?

Конечно, США

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

S>Нет, не понимаю. Я понимаю, почему они не осилили программу ВУЗ-а. А почему не смогут осилить — не понимаю. Если хорошо прижмет — осилят и программу и сикп. Но раз это не требуется, то какой для них в этом смысл?

Теоретически все могут всё. Эта часть вобщем не интересна, так как далека от реальности. Есть вагон причин, по которым люди не смогли осилить. И дело здесь не в том, что слабо прижимали или книги были не той системы. Если эти причины не устранить, сикп не видать.

I>>Даже больше — после этого вуза еще и работают в ИТ.

S>Это не больше, это меньше. В ИТ работают даже сантехники, т.е. люди с образованием сантехника. Я вполне реально, у меня есть знакомый, который месяц поиграл в фотошоп и устроился директором редакционно-издательского отдела в госуниверситет. Есть и обратные примеры, когда краснодипломник ВМК МГУ смог заниматься лишь санацией компьютеров, больше ни на что не был годен.
S>Так что, то что ты работаешь в ИТ еще не значит ничего о твоей квалификации.

Если работают сантехники, то однозначно слабая математика ен является узким местом.

S>3/4 от тысячи средней квалификации получает корочки и уходит работать не по профилю. Остальные куда-то пристраиваются и поднимают квалификацию дальше. Никто не готовит пару экстремально высокой квалификации.


Зачем им уходить работать не по профилю, если в ИТ зарплаты вдвое-втрое выше чем в среднем по стране и достаются почти без особо труда ?

S>Вот как происходит. Допустим, некая серьезная контора, испытывающая недостаток в квалифицированных кадрах пытается встроиться в процесс обучения. Они направляют своего сотрудника в универ и оплачивают ему академические часы по такой ставке, что тот не теряет в зарплате. Этот сотрудник читает лекции, ведет практику и из выпускников отбирает пару продвинутых и делает им предложение об устройстве. Ничего экстемального в этом нет, просто пара подающих надежду и остальные. Эта пара в суперспециалистов превратится не раньше чем через 3-4 года работы.


Это капля в море, все конторы так не смогут, только единицы из самых крупных. И то молодые специалисты уходят на другие конторы, т.к. в крупных конторах ЗП в среднем ниже.

S>Это я тебе привел пример обратной связи между потребителем спецов и поставщиком. Явление не сильно распространенное, но и не редкость. А вот изменение программы/стандартов образования — это под силу только на уровне министерств, причем, как правило эффект от этого негативный.


Странно, и как это мит с гарвардом и им подобные остаются на плаву — совершенно не ясно

I>>Вот по таким принципам и строится все российское образование, результаты не удивляют.

S>Я не понимаю, каких ты хочешь результатов? Обвала рынка ИТ специалистов? Вряд ли ты его получишь в длительной перспективе.

Да вроде все к тому давно уже идет.

>Увеличится выпуск специалистов, их качество уменьшится, увеличится и их отток в другие области, в том числе торговлю телефонами/мебелью. И ты опять будешь переживать за индустрию.


Когда начнется отток в другие области, это значит что
1. отрасль "укомплектована" и начнется жОсткая конкуренция за вакансию( а не наоборот, как сейчас) -> уровень спецов повысится
2. ЗП будут соответствовать выполняемой работе -> девелоперские конторы будут укрупняться и может даже станут градообразующими предприятими
То есть, всё в порядке.
Re[49]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 12:04
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Крутых вузов единицы. Ну может штук 10 по всей россии и потому выхлоп от них на общем фоне не виде.

S>>Может ты мне покажешь пример страны с тысячей куртых вузов, которые дают ощутимый выхлоп на общем фоне?

I>Конечно, США

Которые экспортируют программистов различного уровня со всего мира? Ну ты даешь...

I>Теоретически все могут всё. Эта часть вобщем не интересна, так как далека от реальности. Есть вагон причин, по которым люди не смогли осилить. И дело здесь не в том, что слабо прижимали или книги были не той системы. Если эти причины не устранить, сикп не видать.

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

S>>Это не больше, это меньше. В ИТ работают даже сантехники, т.е. люди с образованием сантехника. Я вполне реально, у меня есть знакомый, который месяц поиграл в фотошоп и устроился директором редакционно-издательского отдела в госуниверситет. Есть и обратные примеры, когда краснодипломник ВМК МГУ смог заниматься лишь санацией компьютеров, больше ни на что не был годен.

S>>Так что, то что ты работаешь в ИТ еще не значит ничего о твоей квалификации.

I>Если работают сантехники, то однозначно слабая математика ен является узким местом.

Ну так это же был твой конек про слабую математику..

S>>3/4 от тысячи средней квалификации получает корочки и уходит работать не по профилю. Остальные куда-то пристраиваются и поднимают квалификацию дальше. Никто не готовит пару экстремально высокой квалификации.


I>Зачем им уходить работать не по профилю, если в ИТ зарплаты вдвое-втрое выше чем в среднем по стране и достаются почти без особо труда ?

Давай ты у них узнаешь, зачем. Я могу только сказать твои же "в силу вагона причин". Из моего выпуска в смежной со специальностью области работает лишь 20%. И только один человек строго по специальности. Не могу сказать что те кто ушел налево в среднем устроились хуже. Кто-то удачно вышел замуж и живет в 4х этажном особняке в Мюнхене, кто-то в банках, кто мебелью торгует, кто фирму секурити держит.

I>Это капля в море, все конторы так не смогут, только единицы из самых крупных. И то молодые специалисты уходят на другие конторы, т.к. в крупных конторах ЗП в среднем ниже.

Министерству образования нет дела до мелких фирм. Судя по всему они сейчас решают задачу, как бы сделать так, что бы утечку мозгов приостановить.

S>>Это я тебе привел пример обратной связи между потребителем спецов и поставщиком. Явление не сильно распространенное, но и не редкость. А вот изменение программы/стандартов образования — это под силу только на уровне министерств, причем, как правило эффект от этого негативный.


I>Странно, и как это мит с гарвардом и им подобные остаются на плаву — совершенно не ясно

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

S>>Я не понимаю, каких ты хочешь результатов? Обвала рынка ИТ специалистов? Вряд ли ты его получишь в длительной перспективе.


I>Да вроде все к тому давно уже идет.

Серьезно? Тут на форуме недавно обсуждалось, правда ли студенты устраиваются от 80к деревянных... 5 лет назад обсуждали ~40к...

>>Увеличится выпуск специалистов, их качество уменьшится, увеличится и их отток в другие области, в том числе торговлю телефонами/мебелью. И ты опять будешь переживать за индустрию.


I>Когда начнется отток в другие области, это значит что

Оглянись, он вовсю идет.
I>1. отрасль "укомплектована" и начнется жОсткая конкуренция за вакансию( а не наоборот, как сейчас) -> уровень спецов повысится
начнется жОсткая конкуренция за вакансию => отток увеличится. Если уровень и повысится, то наглости, а не качества.
I>2. ЗП будут соответствовать выполняемой работе -> девелоперские конторы будут укрупняться и может даже станут градообразующими предприятими
Обвал ЗП вызовет отток. Зачем будет учитсья именно на программиста при прочих равных?
I>То есть, всё в порядке.
в теории, спасибо зарядке
Re[38]: Императивное программирование
От: vdimas Россия  
Дата: 17.10.12 12:30
Оценка:
Здравствуйте, samius, Вы писали:

S>Формулы действительно могут вычислятся в разном порядке — согласен. Но отсюда никак не следует что не существует ни одной формулы, которая бы требовала определенного порядка операций. Т.е. ты опять доказываешь что-то общее частными случаями.


Я лишь показываю, что этот порядок может зависеть не столько от формулы, сколько от низлежащего вычислителя. Кстате, не попробуешь на досуге изобрести такую формулу (см выделенное)? ))


S>>>А что если я тебе дам выражение с приоритетами, для которого нет соответствующего проца, считающего его за такт? Соберешь такой проц?


V>>Очевидно, ты просто не понимаешь бета-редукцию или постоянно про нее забываешь. Боюсь, кроме как на ветвлении продемонстрировать приоритеты тебе будет сложно. Ведь в общем случае a и b — это выражения (ф-ии), которые, к тому же, вполне могут быть раскрыты "по-месту". Например, в примере с синусами это могли быть:

V>>a(x)=0.5*(x^3-x)
V>>b(x)=0.5*(x^3+x)
V>>Заметь этом случае явно удобнее вычислить (a+b) и (a-b), и последующее разложение в ряд Тейлора даст кучу совпадающих степеных членов для обоих многочленов, последующее вычитание которых существенно сократит результирующий многочлен.
S>И опять "вполне могут быть". А могут и не быть.

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


V>>А ну да. Опять этот твой неоспоримый аргумент: "не может быть!".


V>>Где "может быть" легко различимая поэтапность в ФП я уже показал.

S>Я не понимаю, почему тебя смущает поэтапность.

Ээээ... меня-то не смущает. Но спор этот начался от того, насколько ФП близко к структурному программированию. Напомню, что основные бодания были вокруг циклов и ветвлений.


V>>Почему происходящее в ветвлении в ФП и СП одинаково — тоже показал не раз. Даже с учетом ленивости.

S>Раз 10 тебя просил показать мне пользу императивного оператора if с чистыми ветками, пользу императивного цикла с чистым телом. Увы...
S>Могу еще попросить показать пользу от последовательности чистых стейтментов. Уверен что кончится тем же.

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


V>>А если некие спекулятивные чистые вычисления ложных веток могут быть выполнены (как настаивают коллеги), то все-равно результат этих вычислений будет отброшен (ими же утверждается, хотя там есть тонкости, на которые они пока ответить не в состоянии). В любом случае, всегда можно считать, что этих вычислений не было — они были совершенны фантомом в параллельном пространстве и самоиспарились. А те вычисления, что нас интересуют — будут упорядоченны именно как я сказал. То бишь даже если во времени (в ФП во времени!!! гы-гы, вот уровень их рассуждений!), где-то будет вычислена положительная ветка раньше, то наблюдаемого результата этих вычислений все-равно не будет до тех пор, пока не будет вычислен предикат. Увы. Т.е. даже в случае автоматического распараллеливания, результат будет отложен как аргумент той самой ленивой ф-ии (в основном потоке вычислений), которая будет упорядочивать все параллельные вычисления. Упорядочивать будет, ес-но, по мере вычисления значений предикатов на ветвлении. Муахаха.. ))

S>Я не вижу проблемы в упорядоченности вычислений. А так же не вижу связи между упорядоченностью чистых вычислений композицией и упорядоченностью императивных вычислений/стейтментов, которые не могут не портить окружение.

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

S>Про автоматическое распараллеливание вообще забей, оно не имеет отношения к обсуждению.


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


V>>====

V>>Это я еще молчу о ветвлении на паттерн-матчинге, где в реальности сейчас происходит реинтерпретация памяти в общем случае, согласно значению дискриминанта алг-типа. Т.е. что именно в ложных ветках паттерн-матчинга можно вычислять в общем случае — это загадка из загадок.
S>Ты о нем молчишь потому как в базисе СП паттерн-матчинга нет и реализовать его на базисе СП не вопрос. Вот и молчи, т.к. никакой сути паттерн-матчинг не меняет. Вычисление жопы достижимо и на if-е.

Ты не понял про интерпретацию памяти. См. что есть алгебраический тип данных. Если в процессе ПМ происходит "распаковка" абстрактного типа и затем участвуют "распакованные" значения конкретных типов, то на ПМ сразу появляется жопа вместо распакованных значений, потому что аргумент ПМ еще неизвестен. То бишь, затем придется подавать жопу как аргумент далее в ветки ПМ, а это можно подавать лишь в те вычисления, которые ее игнорируют (хотя, такие вычисления должны избавляться от игнорируемого аргумента еще на этапе бета-редукции).
Re[39]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 13:18
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Формулы действительно могут вычислятся в разном порядке — согласен. Но отсюда никак не следует что не существует ни одной формулы, которая бы требовала определенного порядка операций. Т.е. ты опять доказываешь что-то общее частными случаями.


V>Я лишь показываю, что этот порядок может зависеть не столько от формулы, сколько от низлежащего вычислителя. Кстате, не попробуешь на досуге изобрести такую формулу (см выделенное)? ))

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

V>>>Заметь этом случае явно удобнее вычислить (a+b) и (a-b), и последующее разложение в ряд Тейлора даст кучу совпадающих степеных членов для обоих многочленов, последующее вычитание которых существенно сократит результирующий многочлен.

S>>И опять "вполне могут быть". А могут и не быть.

V>Боюсь, наличие более одного варианта вычислений играет мне на руку в этом споре.

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

V>>>А ну да. Опять этот твой неоспоримый аргумент: "не может быть!".


V>>>Где "может быть" легко различимая поэтапность в ФП я уже показал.

S>>Я не понимаю, почему тебя смущает поэтапность.

V>Ээээ... меня-то не смущает. Но спор этот начался от того, насколько ФП близко к структурному программированию. Напомню, что основные бодания были вокруг циклов и ветвлений.

Спор был не о том, насколько близко, ведь меру никто не предложил пока. Спор был о том, происходит ли ФП от СП. Ты доказывал что происходит. Т.е. речь была не о степени близости, а о факте происхождения.

V>>>Почему происходящее в ветвлении в ФП и СП одинаково — тоже показал не раз. Даже с учетом ленивости.

S>>Раз 10 тебя просил показать мне пользу императивного оператора if с чистыми ветками, пользу императивного цикла с чистым телом. Увы...
S>>Могу еще попросить показать пользу от последовательности чистых стейтментов. Уверен что кончится тем же.

V>Сформулируй "пользу".

Пусть будет влиянием на значение результата вычислений. Но не время, такты процессора и т.п.
V>Почему переспросил? Тут некоторые считают (и где-то правы), что введение промежуточных иммутабельных переменных и выражение вычислительного потока с помощью последовательности независимых (на каждом шаге) вычислений с участием этих иммутабельных переменных вполне себе ФП.
Что-то я не понял, о чем речь. Можешь на пальцах?
V>Дык, твою "пользу" вполне можно получить на самом последнем шаге, при подаче целевых таких вычисленных "переменных" куда-нить в "мир" в конце цепочки вычислений.
Я тебя прошу показать пользу условного оператора с чистыми ветками, либо цикла с чистым телом, либо сиквенса с чистыми стейтментами. Как они могут влиять на результат вычислений, кроме нагрева атмосферы?

V>>>А если некие спекулятивные чистые вычисления ложных веток могут быть выполнены (как настаивают коллеги), то все-равно результат этих вычислений будет отброшен (ими же утверждается, хотя там есть тонкости, на которые они пока ответить не в состоянии). В любом случае, всегда можно считать, что этих вычислений не было — они были совершенны фантомом в параллельном пространстве и самоиспарились. А те вычисления, что нас интересуют — будут упорядоченны именно как я сказал. То бишь даже если во времени (в ФП во времени!!! гы-гы, вот уровень их рассуждений!), где-то будет вычислена положительная ветка раньше, то наблюдаемого результата этих вычислений все-равно не будет до тех пор, пока не будет вычислен предикат. Увы. Т.е. даже в случае автоматического распараллеливания, результат будет отложен как аргумент той самой ленивой ф-ии (в основном потоке вычислений), которая будет упорядочивать все параллельные вычисления. Упорядочивать будет, ес-но, по мере вычисления значений предикатов на ветвлении. Муахаха.. ))

S>>Я не вижу проблемы в упорядоченности вычислений. А так же не вижу связи между упорядоченностью чистых вычислений композицией и упорядоченностью императивных вычислений/стейтментов, которые не могут не портить окружение.

V>Не подменяй тему. Я утверждал лишь, что оно есть, и что на это можно полагаться. Я ни разу не считал это проблемой. Просто это опять на руку мне, что любые наблюдаемые вычисления могут идти лишь в таком же самом порядке, как в СП.

Что такое наблюдаемые вычисления в отношении к ФП? Если ты о действиях императивного вычислителя, то иди лесом.

S>>Про автоматическое распараллеливание вообще забей, оно не имеет отношения к обсуждению.


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

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

S>>Ты о нем молчишь потому как в базисе СП паттерн-матчинга нет и реализовать его на базисе СП не вопрос. Вот и молчи, т.к. никакой сути паттерн-матчинг не меняет. Вычисление жопы достижимо и на if-е.


V>Ты не понял про интерпретацию памяти. См. что есть алгебраический тип данных. Если в процессе ПМ происходит "распаковка" абстрактного типа и затем участвуют "распакованные" значения конкретных типов, то на ПМ сразу появляется жопа вместо распакованных значений, потому что аргумент ПМ еще неизвестен.

Условие if-а тоже неизвестно, так что жопа может появиться в любой из 2х его веток, даже возвращающих константы.

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

тут я не понял
Re[50]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.10.12 13:20
Оценка:
Здравствуйте, samius, Вы писали:

I>>Конечно, США

S>Которые экспортируют программистов различного уровня со всего мира? Ну ты даешь...

Импортируют. Есть две тенденции, часть проектов уходит в США, часть уходит из США. Уходит много больше. А импортировать все равно выгодно, посколько возможности системы образования во первых, ограничены, во вторых, сказываются в долгосрочной перспективе.
Если человек нужен здесь и сейчас — его надо импортировать. Успешность такой политики показывает пример Израиля и США. А вот если забить на образование, то в долгосрочной перспективе этот импорт обязательно вылезет боком, т.к. передачу опыта делает в основном система образования.

I>>Теоретически все могут всё. Эта часть вобщем не интересна, так как далека от реальности. Есть вагон причин, по которым люди не смогли осилить. И дело здесь не в том, что слабо прижимали или книги были не той системы. Если эти причины не устранить, сикп не видать.

S>Т.е. ты не можешь объяснить, почему они не смогут осилить сикп, кроме как сказать "в силу вагона причин".

Я уже пятьсот раз объяснял эти причины, а ты только отплёвывался. Вобщем мне надоедает повторять одно и то же по нескольку раз.

I>>Если работают сантехники, то однозначно слабая математика ен является узким местом.

S>Ну так это же был твой конек про слабую математику..

Конечно, я и говорю — пока в отрасли много сантехников, про бетаредукцию можно забыить.

I>>Зачем им уходить работать не по профилю, если в ИТ зарплаты вдвое-втрое выше чем в среднем по стране и достаются почти без особо труда ?

S>Давай ты у них узнаешь, зачем. Я могу только сказать твои же "в силу вагона причин". Из моего выпуска в смежной со специальностью области работает лишь 20%. И только один человек строго по специальности. Не могу сказать что те кто ушел налево в среднем устроились хуже. Кто-то удачно вышел замуж и живет в 4х этажном особняке в Мюнхене, кто-то в банках, кто мебелью торгует, кто фирму секурити держит.

А ты в ИТ специальности учился или где ? У нас в ИТ работало около 100% выпуска.

I>>Это капля в море, все конторы так не смогут, только единицы из самых крупных. И то молодые специалисты уходят на другие конторы, т.к. в крупных конторах ЗП в среднем ниже.

S>Министерству образования нет дела до мелких фирм. Судя по всему они сейчас решают задачу, как бы сделать так, что бы утечку мозгов приостановить.

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

I>>Странно, и как это мит с гарвардом и им подобные остаются на плаву — совершенно не ясно

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

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

I>>Да вроде все к тому давно уже идет.

S>Серьезно? Тут на форуме недавно обсуждалось, правда ли студенты устраиваются от 80к деревянных... 5 лет назад обсуждали ~40к...

Правильный симптом. Много ли студентов в других областях могут похвастаться такими ЗП ? Опаньки !

I>>Когда начнется отток в другие области, это значит что

S>Оглянись, он вовсю идет.

Я вижу что больше и больше желающих работать в ИТ и получать большие ЗП. Основной отток идет за счет тех, кто "прошел ИТ". Просто потмоу что в ИТ довольно тяжело работать — надо постоянно чтото изучать и пробовать, при чем в большинстве случаев эти знания-опыт через пять-десять лет станут невостребоваными.
Приход в любом случае больше этого оттока.

I>>1. отрасль "укомплектована" и начнется жОсткая конкуренция за вакансию( а не наоборот, как сейчас) -> уровень спецов повысится

S>начнется жОсткая конкуренция за вакансию => отток увеличится. Если уровень и повысится, то наглости, а не качества.

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

I>>2. ЗП будут соответствовать выполняемой работе -> девелоперские конторы будут укрупняться и может даже станут градообразующими предприятими

S>Обвал ЗП вызовет отток. Зачем будет учитсья именно на программиста при прочих равных?

За тем же, зачем сейчас учатся на учителей, врачей и тд и тд. — просто потому что нравится.
Re[51]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 16:37
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Конечно, США

S>>Которые экспортируют программистов различного уровня со всего мира? Ну ты даешь...

I>Импортируют. Есть две тенденции, часть проектов уходит в США, часть уходит из США. Уходит много больше. А импортировать все равно выгодно, посколько возможности системы образования во первых, ограничены, во вторых, сказываются в долгосрочной перспективе.

I>Если человек нужен здесь и сейчас — его надо импортировать. Успешность такой политики показывает пример Израиля и США. А вот если забить на образование, то в долгосрочной перспективе этот импорт обязательно вылезет боком, т.к. передачу опыта делает в основном система образования.
Заелозил опять. Ты сравни объем импорта США ИТ-шников и объем экспорта. И потом ответь на вопрос, покрывают ли ВУЗ-ы США их потребности. И если нет, то чьи ВУЗ-ы покрывают потребности США?

I>>>Теоретически все могут всё. Эта часть вобщем не интересна, так как далека от реальности. Есть вагон причин, по которым люди не смогли осилить. И дело здесь не в том, что слабо прижимали или книги были не той системы. Если эти причины не устранить, сикп не видать.

S>>Т.е. ты не можешь объяснить, почему они не смогут осилить сикп, кроме как сказать "в силу вагона причин".

I>Я уже пятьсот раз объяснял эти причины, а ты только отплёвывался. Вобщем мне надоедает повторять одно и то же по нескольку раз.

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

I>>>Если работают сантехники, то однозначно слабая математика ен является узким местом.

S>>Ну так это же был твой конек про слабую математику..

I>Конечно, я и говорю — пока в отрасли много сантехников, про бетаредукцию можно забыить.

Чушь. Про нее можно забыть пока знание ее не станет нормой. А оно не станет, если студентов беречь от таких знаний. Да и неслабо у сантехников с бетаредукцией. Цены от прокладок подставляют в смету на счет раз.

I>А ты в ИТ специальности учился или где ? У нас в ИТ работало около 100% выпуска.

Или где.

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

Как не в силах? В силах. Они саботируют систему образования.

I>>>Странно, и как это мит с гарвардом и им подобные остаются на плаву — совершенно не ясно

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

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

I>Ну нужна уравниловка ни "все богатые", ни "все бедные". Уравнивать вообще не нужно.
Ты же предлагаешь делать 1000 запорожцев, не я.

I>>>Да вроде все к тому давно уже идет.

S>>Серьезно? Тут на форуме недавно обсуждалось, правда ли студенты устраиваются от 80к деревянных... 5 лет назад обсуждали ~40к...

I>Правильный симптом. Много ли студентов в других областях могут похвастаться такими ЗП ? Опаньки !

Опаньки Так рост ЗП в отрасли это симптом насыщения?

I>>>Когда начнется отток в другие области, это значит что

S>>Оглянись, он вовсю идет.

I>Я вижу что больше и больше желающих работать в ИТ и получать большие ЗП. Основной отток идет за счет тех, кто "прошел ИТ". Просто потмоу что в ИТ довольно тяжело работать — надо постоянно чтото изучать и пробовать, при чем в большинстве случаев эти знания-опыт через пять-десять лет станут невостребоваными.

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

S>>начнется жОсткая конкуренция за вакансию => отток увеличится. Если уровень и повысится, то наглости, а не качества.


I>Если ты будешь платить за наглость, а не за качество решения, то конечно же будет наглость прокачиваться.

Это не от меня зависит. Если наглецы греют рынок, то квалифицированные спецы подтягиваются за ними. Кроме тех, что за еду готовы.

S>>Обвал ЗП вызовет отток. Зачем будет учитсья именно на программиста при прочих равных?


I>За тем же, зачем сейчас учатся на учителей, врачей и тд и тд. — просто потому что нравится.

Нравится? Тех кому нравится учить и лечить — там от силы 30%. Остальные преспокойно (м)учат и (ка)лечат до тех пор пока случай не представится залезть повыше и плевать подальше. Есть масса тому подтверждений.
Re[41]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 17.10.12 17:06
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Да, с формулами сложновато, если они не содержат условных операций.


V>ЧТД.

V>Дать ссылку на определение СП?
V>Опять помусолим, насколько близки ФП и СП? )))
да я что-то уже намусолился тебе мусолить что не близки они.

V>Ну реально, чистота СП-процедур и ф-ий запросто видна компилятором. То бишь, эту чистоту можно распространять себе в СП с тем же успехом, как это происходит в ФП. Всего-то навсего надо отказаться от глобальных/статических переменных. И вот уже императив становится ничем не хуже ФП. Там терия автоматов, тут комбинаторика ф-ий. Одно стоит другого.

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

V>>>Ээээ... меня-то не смущает. Но спор этот начался от того, насколько ФП близко к структурному программированию. Напомню, что основные бодания были вокруг циклов и ветвлений.

S>>Спор был не о том, насколько близко, ведь меру никто не предложил пока. Спор был о том, происходит ли ФП от СП. Ты доказывал что происходит. Т.е. речь была не о степени близости, а о факте происхождения.

V>Тебе не стыдно, положив болт на один из своих предыдущих аргументов, тут же выдвигать какой-то новый? ))

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

V>Я не могу точно знать кто от кого произошел в теории, ес-но, хотя бы потому, что речь о практических парадигмах (лямда-исчисление и ФП-парадигма — это не совсем одно и то же). К тому же, вложение областей видимости в СП (основа основ СП) — это один-в-один вложение лямбд без явно объявленных связываемых аргументов (вспомни споры о "замыканиях" в Паскале). Именно так. Просто, коль речь о практических парадигмах в программировании, то СП утряслось в языках раньше чистого ФП. Более того, все первые ФП-языки относились скорее к СП-языкам, у которых дополнительно к СП появились ФВП (например, Lisp, APL, ML).

Что там утряслось раньше — не сильно интересно. Ты задвигал о происхождении от

S>>>>Раз 10 тебя просил показать мне пользу императивного оператора if с чистыми ветками, пользу императивного цикла с чистым телом. Увы...

S>>>>Могу еще попросить показать пользу от последовательности чистых стейтментов. Уверен что кончится тем же.

V>>>Сформулируй "пользу".

S>>Пусть будет влиянием на значение результата вычислений. Но не время, такты процессора и т.п.

V>Дык, сто раз показывал. Мутации локально-видимых данных всегда чисты.

Что за чушь? Я тебя просил не чистые функции с мутацией локальных переменных, а if/for/; с чистыми стейтментами, т.е. такими, которые не изменяют внешнее состояние. Возьми в качестве стейтмента чистую функцию — не вопрос. Но раз твой структурный if не испортил что-то, определенное извне его — значит он лишний. Твой код я скипаю, т.к. ничего другого от тебя не ждал.

V>Специально расписал на промежуточных мутабельных переменных, чтобы показать, что мутабельность не значит отсутствия чистоты вычислений. Я тебе ссылку на определение чистоты вычислений уже давал, помнится.

Печально что ты не смог применить определение к ветке if-а.

V>>>Почему переспросил? Тут некоторые считают (и где-то правы), что введение промежуточных иммутабельных переменных и выражение вычислительного потока с помощью последовательности независимых (на каждом шаге) вычислений с участием этих иммутабельных переменных вполне себе ФП.

S>>Что-то я не понял, о чем речь. Можешь на пальцах?

V>Тогда фиг с ним.

V>(Суть в том, что в случае иммутабельности, переменная с тем же успехом является символом для подстановки правой части выражения присваивания, а не реально-существующей ячейкой памяти.)
Тут суть не в иммутабельности а в контексте. А не понял я про введение промежуточных иммутабельных переменных и выражение высилительного потока.

S>>Я тебя прошу показать пользу условного оператора с чистыми ветками, либо цикла с чистым телом, либо сиквенса с чистыми стейтментами. Как они могут влиять на результат вычислений, кроме нагрева атмосферы?


V>Могут...

Ты не показал
V>Теперь понимаешь, почему я занимаюсь просветительской деятельностью тут? )))
Еще больше не понимаю. Тебя бы самого кто просветил.

V>ФП стало слишком модным, многие в него подавшиеся не совсем отчетливо понимают, о чем идёт речь и для всё это было надо.

По-моему ты не совсем отчетливо понимаешь, в частности смысл теоремы Б/Я

S>>Что такое наблюдаемые вычисления в отношении к ФП? Если ты о действиях императивного вычислителя, то иди лесом.


V>Я назвал наблюдаемыми те вычисления, которые влияют на конечный результат. Пусть себе вычислитель будет полностью чист до самой последней инструкции, в которой ответ выводится во внешний мир.

Я не понимаю тебя.

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


V>Не надоело подставляться?

Твои же штучки

S>>Условие if-а тоже неизвестно, так что жопа может появиться в любой из 2х его веток, даже возвращающих константы.


V>Может, ес-но. А может и нет. А в ПМ всегда жопа, когда есть зависимость от результата распаковки абстрактного типа.

То есть как и в if, в ПМ жопа не всегда

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

S>>тут я не понял

V>Ну дык не все ветки ПМ юзают распакованные значения. Как крайний случай — смотри ПМ по некоему enum. Там простое ветвление, как на if.

Теперь понял, но отличий от if от этого не прибавилось.
Re[52]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.10.12 10:30
Оценка:
Здравствуйте, samius, Вы писали:

I>>Если человек нужен здесь и сейчас — его надо импортировать. Успешность такой политики показывает пример Израиля и США. А вот если забить на образование, то в долгосрочной перспективе этот импорт обязательно вылезет боком, т.к. передачу опыта делает в основном система образования.

S>Заелозил опять. Ты сравни объем импорта США ИТ-шников и объем экспорта. И потом ответь на вопрос, покрывают ли ВУЗ-ы США их потребности. И если нет, то чьи ВУЗ-ы покрывают потребности США?

Я уже объяснил внятно — возможности системы образования в краткосрочной перспективе сильно ограничены. Если нужны спецы здесь и сейачс есть только один единственный выход — импортировать.

I>>Я уже пятьсот раз объяснял эти причины, а ты только отплёвывался. Вобщем мне надоедает повторять одно и то же по нескольку раз.

S>Ты уже который раз написал "теоретически все могут все". Если больше нечего, то не пиши это еще раз.

Люди, которые пошли в рязанский, просто не могли поступить в МИФИ скажем. Потому, например, что школьная база слабая. "выжать" не получится, просто потому что нечего выжимать. Не в курсе понимаешь ли ты это, но с девушки можно снять только то, что на ней надето.

I>>Конечно, я и говорю — пока в отрасли много сантехников, про бетаредукцию можно забыить.

S>Чушь. Про нее можно забыть пока знание ее не станет нормой. А оно не станет, если студентов беречь от таких знаний. Да и неслабо у сантехников с бетаредукцией. Цены от прокладок подставляют в смету на счет раз.

Это ничего не значит.

I>>А ты в ИТ специальности учился или где ? У нас в ИТ работало около 100% выпуска.

S>Или где.

То есть, твои фантазии на эту тему можно игнорировать.

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

S>Как не в силах? В силах. Они саботируют систему образования.

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

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

I>>Ну нужна уравниловка ни "все богатые", ни "все бедные". Уравнивать вообще не нужно.
S>Ты же предлагаешь делать 1000 запорожцев, не я.

Я предлагаю работать с тем что есть и постепенно устранять некоторые недостатки. А если спустить сверху СИКП то это просто уравниловка по принципу "все богатые".

I>>Правильный симптом. Много ли студентов в других областях могут похвастаться такими ЗП ? Опаньки !

S>Опаньки Так рост ЗП в отрасли это симптом насыщения?

Ты на вопрос отвечай, а то у меня нет желания продираться через твои домыслы.

I>>Приход в любом случае больше этого оттока.

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

Точно, пальцем в небо !

I>>Если ты будешь платить за наглость, а не за качество решения, то конечно же будет наглость прокачиваться.

S>Это не от меня зависит. Если наглецы греют рынок, то квалифицированные спецы подтягиваются за ними. Кроме тех, что за еду готовы.

Рынок греют не наглецы, а бизнес который платит за результат. Бизнес этот никогда не будет платить тупо за наглость, им результат нужен. Если раньше нужно было хоть чтото, то сейчас уже требуют нефункциональных возможностей, навроде качества.

I>>За тем же, зачем сейчас учатся на учителей, врачей и тд и тд. — просто потому что нравится.

S>Нравится? Тех кому нравится учить и лечить — там от силы 30%. Остальные преспокойно (м)учат и (ка)лечат до тех пор пока случай не представится залезть повыше и плевать подальше. Есть масса тому подтверждений.

Особенности твоего восприятия не будем обсуждать, я помню по предыдущим разговорам, "как все плохо вокруг".
Re[52]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.10.12 11:02
Оценка:
Здравствуйте, samius, Вы писали:

S>Заелозил опять. Ты сравни объем импорта США ИТ-шников и объем экспорта. И потом ответь на вопрос, покрывают ли ВУЗ-ы США их потребности. И если нет, то чьи ВУЗ-ы покрывают потребности США?


Ничего, если тебе сам Барак Обама ответит ?
"Если мы не обучаем инженеров, чтобы они были обеспечены всем необходимым — то компании сюда [в США] не придут."
Re[33]: Императивное программирование
От: artelk  
Дата: 18.10.12 11:22
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Если честно, забодал подменой темы обсуждения. Речь была о упорядочивании вычислений, а не о чистоте. 99% ф-ий в современном императиве тоже чисты и что с того? Императива не существет?

Если бы в качестве предиката было (x>1), то во втором примере возникла бы упорядоченность вычислений?
Re[53]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.10.12 07:01
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Заелозил опять. Ты сравни объем импорта США ИТ-шников и объем экспорта. И потом ответь на вопрос, покрывают ли ВУЗ-ы США их потребности. И если нет, то чьи ВУЗ-ы покрывают потребности США?


I>Я уже объяснил внятно — возможности системы образования в краткосрочной перспективе сильно ограничены. Если нужны спецы здесь и сейачс есть только один единственный выход — импортировать.

Это только один из выходов. И в долгосрочной перспективе он означает обширный экспорт доморощенных спецов. Мы его наблюдаем? Я- нет.

S>>Ты уже который раз написал "теоретически все могут все". Если больше нечего, то не пиши это еще раз.


I>Люди, которые пошли в рязанский, просто не могли поступить в МИФИ скажем. Потому, например, что школьная база слабая. "выжать" не получится, просто потому что нечего выжимать.

Это не повод считать что сикп не пролезет.

S>>Чушь. Про нее можно забыть пока знание ее не станет нормой. А оно не станет, если студентов беречь от таких знаний. Да и неслабо у сантехников с бетаредукцией. Цены от прокладок подставляют в смету на счет раз.


I>Это ничего не значит.

Это значит что бетаредукцией они владеют в некоторой степени.

S>>Или где.


I>То есть, твои фантазии на эту тему можно игнорировать.

Конечно можно. Не думал ли ты что я на тебя накричу и в суд подам за это?

S>>Как не в силах? В силах. Они саботируют систему образования.


I>Пусть саботируют, на утечку мозгов это влияет сильно слабо. Побуждает уехать из страны не слабый уровень образования, а отсутствие возможностей для реализации + возможность этой реализации в другом месте, то есть, если упростить, разница в уровнях жизни. Минобразования здесь вообще никаким боком.

Еще каким боком. ИТ-шники уезжают работать не на заправку ведь и не швеями-мотористками. Подумай об этом.

S>>Ты же предлагаешь делать 1000 запорожцев, не я.


I>Я предлагаю работать с тем что есть и постепенно устранять некоторые недостатки. А если спустить сверху СИКП то это просто уравниловка по принципу "все богатые".

Не больше уравниловка, чем спущенаая сверху вышка или философия.

I>>>Правильный симптом. Много ли студентов в других областях могут похвастаться такими ЗП ? Опаньки !

S>>Опаньки Так рост ЗП в отрасли это симптом насыщения?

I>Ты на вопрос отвечай, а то у меня нет желания продираться через твои домыслы.

Вопрос был к тебе. Это твой ответ про то что все идет к обвалу и рост ЗП симптом тому.

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


I>Точно, пальцем в небо !

Раз точно, то насыщением/обвалом не пахнет, не находишь?

S>>Это не от меня зависит. Если наглецы греют рынок, то квалифицированные спецы подтягиваются за ними. Кроме тех, что за еду готовы.


I>Рынок греют не наглецы, а бизнес который платит за результат. Бизнес этот никогда не будет платить тупо за наглость, им результат нужен.

Противоречие не видишь?

S>>Нравится? Тех кому нравится учить и лечить — там от силы 30%. Остальные преспокойно (м)учат и (ка)лечат до тех пор пока случай не представится залезть повыше и плевать подальше. Есть масса тому подтверждений.


I>Особенности твоего восприятия не будем обсуждать, я помню по предыдущим разговорам, "как все плохо вокруг".

За своим восприятием бди
Re[53]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.10.12 07:03
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Заелозил опять. Ты сравни объем импорта США ИТ-шников и объем экспорта. И потом ответь на вопрос, покрывают ли ВУЗ-ы США их потребности. И если нет, то чьи ВУЗ-ы покрывают потребности США?


I>Ничего, если тебе сам Барак Обама ответит ?

I>"Если мы не обучаем инженеров, чтобы они были обеспечены всем необходимым — то компании сюда [в США] не придут."
Такое ощущение что Обама не читал мой вопрос и отвеал на что-то другое
Re[54]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.10.12 09:05
Оценка:
Здравствуйте, samius, Вы писали:

I>>Я уже объяснил внятно — возможности системы образования в краткосрочной перспективе сильно ограничены. Если нужны спецы здесь и сейачс есть только один единственный выход — импортировать.

S>Это только один из выходов. И в долгосрочной перспективе он означает обширный экспорт доморощенных спецов. Мы его наблюдаем? Я- нет.

Ты чего то попутал. С какого бодуна штаты вдруг начнут экспортировать спецов ? Сам посмотри — чуть не все высокотехнологичные конторы, сконцентрированы в США.
Производство можно и в китай отдать, а для спецов проще создать условия, что бы новые конторы плодились.

I>>Люди, которые пошли в рязанский, просто не могли поступить в МИФИ скажем. Потому, например, что школьная база слабая. "выжать" не получится, просто потому что нечего выжимать.

S>Это не повод считать что сикп не пролезет.

Официально дать его можно. А вот выхлопа ждать вряд ли стоит. Невозможно школьные пробелы компенсировать принудиловкой да в короткий срок, если такое устроишь, будет прорыв в образовании, так что записывайся в очередь на Нобелевку И еще момент — сикп это вагон работы на стороне кафедры. Каким образом кафедра это потянет, если сейчас выпуск методички и то подвигом считается ?

I>>Это ничего не значит.

S>Это значит что бетаредукцией они владеют в некоторой степени.

И откуда уверенность, что этого уровня владения достаточно для программирования ?

I>>То есть, твои фантазии на эту тему можно игнорировать.

S>Конечно можно. Не думал ли ты что я на тебя накричу и в суд подам за это?

Я думаю что ты и накричать не сможешь

I>>Пусть саботируют, на утечку мозгов это влияет сильно слабо. Побуждает уехать из страны не слабый уровень образования, а отсутствие возможностей для реализации + возможность этой реализации в другом месте, то есть, если упростить, разница в уровнях жизни. Минобразования здесь вообще никаким боком.

S>Еще каким боком. ИТ-шники уезжают работать не на заправку ведь и не швеями-мотористками. Подумай об этом.

Вобще говоря ты прав — что бы ИТ-специалисты не уезжали за границу, нужно всего навсего перестать их готовить, утечка мозгов внезапно остановится.

I>>Я предлагаю работать с тем что есть и постепенно устранять некоторые недостатки. А если спустить сверху СИКП то это просто уравниловка по принципу "все богатые".

S>Не больше уравниловка, чем спущенаая сверху вышка или философия.

Вышка нужна любому инженеру. А ты предлагаешь не просто ввести программуху, она уже давно введена, а тупо задрать планку не понятно на каком основании.

I>>Ты на вопрос отвечай, а то у меня нет желания продираться через твои домыслы.

S>Вопрос был к тебе. Это твой ответ про то что все идет к обвалу и рост ЗП симптом тому.

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

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


I>>Точно, пальцем в небо !

S>Раз точно, то насыщением/обвалом не пахнет, не находишь?

Да, завтра его точно не будет, ты прав.

I>>Рынок греют не наглецы, а бизнес который платит за результат. Бизнес этот никогда не будет платить тупо за наглость, им результат нужен.

S>Противоречие не видишь?

Здесь нет противоречия. Но судя по тому, как ты домыслы строишь, я даже и не удивляюсь уже
Re[54]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 19.10.12 09:05
Оценка:
Здравствуйте, samius, Вы писали:

I>>Ничего, если тебе сам Барак Обама ответит ?

I>>"Если мы не обучаем инженеров, чтобы они были обеспечены всем необходимым — то компании сюда [в США] не придут."
S>Такое ощущение что Обама не читал мой вопрос и отвеал на что-то другое

Разумеется он не читал твой вопрос,да и говорил он не только про образование.
Re[55]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.10.12 09:28
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Я уже объяснил внятно — возможности системы образования в краткосрочной перспективе сильно ограничены. Если нужны спецы здесь и сейачс есть только один единственный выход — импортировать.

S>>Это только один из выходов. И в долгосрочной перспективе он означает обширный экспорт доморощенных спецов. Мы его наблюдаем? Я- нет.

I>Ты чего то попутал. С какого бодуна штаты вдруг начнут экспортировать спецов ? Сам посмотри — чуть не все высокотехнологичные конторы, сконцентрированы в США.

С твоего бодуна. Если бы США готовило достаточное для своих нужд количество специалистов и плюс к тому бы импортировало, то им пришлось бы так же и экспортировать их. Либо топить своих специалистов как котят в унитазе.
I>Производство можно и в китай отдать, а для спецов проще создать условия, что бы новые конторы плодились.
Спецов можно и в Индии/Украине прикармливать а себе оставить управление/маркетинг.
Но речь лишь о том что они выпускают спецов меньше чем могли бы проглотить. Потому твой пример с США идет лесом. Индия может быть твой идеал?

S>>Это не повод считать что сикп не пролезет.


I>Официально дать его можно. А вот выхлопа ждать вряд ли стоит. Невозможно школьные пробелы компенсировать принудиловкой да в короткий срок, если такое устроишь, будет прорыв в образовании, так что записывайся в очередь на Нобелевку И еще момент — сикп это вагон работы на стороне кафедры. Каким образом кафедра это потянет, если сейчас выпуск методички и то подвигом считается ?

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

S>>Это значит что бетаредукцией они владеют в некоторой степени.

I>И откуда уверенность, что этого уровня владения достаточно для программирования ?
Откуда уверенность что если сантехника посадить рядом со вчерашним школьником, который не умеет подставлять значения в формулу, то успехи сантехника в программировании будут заметно хуже? При прочих равных, конечно, когда у сантехника шланги не горят и печень не просит занять и выпить.

I>Я думаю что ты и накричать не сможешь

Проницательный, блин

S>>Еще каким боком. ИТ-шники уезжают работать не на заправку ведь и не швеями-мотористками. Подумай об этом.


I>Вобще говоря ты прав — что бы ИТ-специалисты не уезжали за границу, нужно всего навсего перестать их готовить, утечка мозгов внезапно остановится.

Или готовить таких, что звать перестанут.

S>>Не больше уравниловка, чем спущенаая сверху вышка или философия.


I>Вышка нужна любому инженеру. А ты предлагаешь не просто ввести программуху, она уже давно введена, а тупо задрать планку не понятно на каком основании.

Куда задрать? Сикп не просит математики выше 5-го класса. Ну или там не помню, метод Ньютона в каком классе проходят. Даже если не пройден, в том же сикпе его и разжовывают.

S>>Вопрос был к тебе. Это твой ответ про то что все идет к обвалу и рост ЗП симптом тому.


I>Мой ответ был про симптоп а не про точный диагноз Ты в курсе, что это разные вещи ? Попробуй ответить на мой вопрос и тебе все станет ясно.

Что за вопрос?

S>>Раз точно, то насыщением/обвалом не пахнет, не находишь?


I>Да, завтра его точно не будет, ты прав.

Походу завтра начнут сикп в наших вузах давать, раз я дважды за одно сообщение прав оказался

I>>>Рынок греют не наглецы, а бизнес который платит за результат. Бизнес этот никогда не будет платить тупо за наглость, им результат нужен.

S>>Противоречие не видишь?

I>Здесь нет противоречия. Но судя по тому, как ты домыслы строишь, я даже и не удивляюсь уже

Оставлю тебе повод для неудивления в качестве упражнения.
Re[55]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 19.10.12 09:29
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Такое ощущение что Обама не читал мой вопрос и отвеал на что-то другое


I>Разумеется он не читал твой вопрос,да и говорил он не только про образование.

Тогда я не буду считать его ответ ответом на мой вопрос.
Re[38]: Императивное программирование
От: vdimas Россия  
Дата: 21.10.12 01:00
Оценка:
Здравствуйте, artelk, Вы писали:

V>>В первой ветке константа, там нечего вычислять. Вторая гораздо интереснее.

A>А как же "2. Если предикат вычислен, то успешная ветка тоже обязательно будет вычислена."?

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

A>Вот, еще реализация придумалась:


Поторопимшись.

A>Запускаем 2 потока для веток

A>Ждем случайное (например, в интервале [0, С1+arg*С2]) количество тактов процессора

Не можешь ты этого делать в SMP.

A>Вычисляем предикат

A>В зависимости от значения предиката, останавливаем поток ненужной ветки (если он еще работает)
A>Ждем поток нужной ветки (если еще не отработал)
A>Берем результат из потока нужной ветки и возвращаем

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


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

A>Реализация с потоками решает проблему бесконечного зацикливания, однако не имеет предопределенной упорядоченности условного оператора.

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

В общем, смотреть до посинения на факториал и думать, что будет происходить на КАЖДОМ шаге в случае твоего варианта ветвления. Потом вспомнить, что реальных программах ветвление поразвесистей обычно, то бишь показатель степень поболе 2-х будет... Потом опять вернуться к моему вопросу насчет распределения выч. ресурсов. Мне как-то сложно представить в обозримом будущем (ближайшие много десятилетий), что на холостые ветки исполнения можно будет тратить на многие порядки больше ресурсов, чем на целевые. В это упираемся и я сразу же об этом спросил. И вопрос пока в силе.
Re[38]: Императивное программирование
От: vdimas Россия  
Дата: 21.10.12 01:05
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В частности, императивная версия функции fac(), построенная компилятором, вполне может выглядеть вот так:


Для Схемы не может. Целое число там не ограничено.
В любом случае, если компилятор может делать какие-то частичные вычисления (путь даже вычислит первые 12 значений для Схемы), это никак не служит док-вом или даже иллюстрацией к общему случаю, когда компилятор таких вещей делать не может. А мне во всех этих рассуждениях любопытен именно второй вариант, ес-но.
Re[42]: Императивное программирование
От: vdimas Россия  
Дата: 21.10.12 01:23
Оценка:
Здравствуйте, samius, Вы писали:

V>>Я не могу точно знать кто от кого произошел в теории, ес-но, хотя бы потому, что речь о практических парадигмах (лямда-исчисление и ФП-парадигма — это не совсем одно и то же). К тому же, вложение областей видимости в СП (основа основ СП) — это один-в-один вложение лямбд без явно объявленных связываемых аргументов (вспомни споры о "замыканиях" в Паскале). Именно так. Просто, коль речь о практических парадигмах в программировании, то СП утряслось в языках раньше чистого ФП. Более того, все первые ФП-языки относились скорее к СП-языкам, у которых дополнительно к СП появились ФВП (например, Lisp, APL, ML).

S>Что там утряслось раньше — не сильно интересно. Ты задвигал о происхождении от

Ну дык оно в силе. См. выделенное очень внимательно... настолько внимательно, насколько сможешь.

S>Что за чушь? Я тебя просил не чистые функции с мутацией локальных переменных, а if/for/; с чистыми стейтментами, т.е. такими, которые не изменяют внешнее состояние.


Я привел тебе именно такие примеры.

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


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


V>>Специально расписал на промежуточных мутабельных переменных, чтобы показать, что мутабельность не значит отсутствия чистоты вычислений. Я тебе ссылку на определение чистоты вычислений уже давал, помнится.

S>Печально что ты не смог применить определение к ветке if-а.

Печально, что ты не понимаешь такого простого и одновременно такого ёмкого определения.
Помочь разобрать его по шагам применительно к моим примерам? Выбирай любуую ветку if любого примера — я поясню происходящее.


V>>Тогда фиг с ним.

V>>(Суть в том, что в случае иммутабельности, переменная с тем же успехом является символом для подстановки правой части выражения присваивания, а не реально-существующей ячейкой памяти.)
S>Тут суть не в иммутабельности а в контексте. А не понял я про введение промежуточных иммутабельных переменных и выражение высилительного потока.

Возьми для примера Немерле. Там имутабельные переменные, но на них выражается вычислительный процесс явным образом. То бишь, тот же самый императив.


V>>Могут...

S>Ты не показал

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


V>>ФП стало слишком модным, многие в него подавшиеся не совсем отчетливо понимают, о чем идёт речь и для всё это было надо.

S>По-моему ты не совсем отчетливо понимаешь, в частности смысл теоремы Б/Я

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

V>>Я назвал наблюдаемыми те вычисления, которые влияют на конечный результат.

S>Я не понимаю тебя.

)))


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


V>>Не надоело подставляться?

S>Твои же штучки

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


V>>Может, ес-но. А может и нет. А в ПМ всегда жопа, когда есть зависимость от результата распаковки абстрактного типа.

S>То есть как и в if, в ПМ жопа не всегда

Да, её нет при операциях с вырожденными значениями алг.тд. В невырожденном случае — всегда.


V>>Ну дык не все ветки ПМ юзают распакованные значения. Как крайний случай — смотри ПМ по некоему enum. Там простое ветвление, как на if.

S>Теперь понял, но отличий от if от этого не прибавилось.

В вырожденном случае ПМ вообще никаких отличий от if, ес-но. Медитировать надо над невырожденным.
Re[43]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.10.12 10:10
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


V>>>Я не могу точно знать кто от кого произошел в теории, ес-но, хотя бы потому, что речь о практических парадигмах (лямда-исчисление и ФП-парадигма — это не совсем одно и то же). К тому же, вложение областей видимости в СП (основа основ СП) — это один-в-один вложение лямбд без явно объявленных связываемых аргументов (вспомни споры о "замыканиях" в Паскале). Именно так. Просто, коль речь о практических парадигмах в программировании, то СП утряслось в языках раньше чистого ФП. Более того, все первые ФП-языки относились скорее к СП-языкам, у которых дополнительно к СП появились ФВП (например, Lisp, APL, ML).

S>>Что там утряслось раньше — не сильно интересно. Ты задвигал о происхождении от

V>Ну дык оно в силе. См. выделенное очень внимательно... настолько внимательно, насколько сможешь.

Увы мне тебя нечем порадовать. Ты даже haskell считаешь СП, чего уж говорить о первых ФП-языках.

S>>Что за чушь? Я тебя просил не чистые функции с мутацией локальных переменных, а if/for/; с чистыми стейтментами, т.е. такими, которые не изменяют внешнее состояние.


V>Я привел тебе именно такие примеры.

Да нет, не привел. Либо ты не понял, что я от тебя хочу, либо кривляешься.

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


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

Это у тебя серьезные проблемы. Я с тебя просил вот это
http://en.wikipedia.org/wiki/Pure_function#Pure_expressions

Извини что стейтментами назвал, но if/loop/sequence не работают с выражениями.


V>>>Специально расписал на промежуточных мутабельных переменных, чтобы показать, что мутабельность не значит отсутствия чистоты вычислений. Я тебе ссылку на определение чистоты вычислений уже давал, помнится.

S>>Печально что ты не смог применить определение к ветке if-а.

V>Печально, что ты не понимаешь такого простого и одновременно такого ёмкого определения.

V>Помочь разобрать его по шагам применительно к моим примерам? Выбирай любуую ветку if любого примера — я поясню происходящее.
В детский сад со своими примерами. Это не то, что я просил.

S>>Тут суть не в иммутабельности а в контексте. А не понял я про введение промежуточных иммутабельных переменных и выражение высилительного потока.


V>Возьми для примера Немерле. Там имутабельные переменные, но на них выражается вычислительный процесс явным образом. То бишь, тот же самый императив.

Ты не понимаешь, что такое императив. Походу не справился с определением.

V>Ты просто убежал в очередной раз. Заканчивай уже бегать. Я привел примеры, давай их разбирать. Я пока еще не воткнул, в чём именно у тебя сложности с их пониманием. Насчет "чистых веток if" — это какой-то бред, ведь в императиве эти ветки не могут быть исполнены в отрыве от контекста. То бишь, чистота веток напрямую зависит от чистоты контекста. Если контекст детерминирован относительно потока вычисления, то ветки if автоматом детерминированы, если исполняются в том же потоке.

см pure expression

S>>По-моему ты не совсем отчетливо понимаешь, в частности смысл теоремы Б/Я


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

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

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


V>>>Не надоело подставляться?

S>>Твои же штучки

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

Как бы там ни было, это не аргумент

V>Да, её нет при операциях с вырожденными значениями алг.тд. В невырожденном случае — всегда.

Меня поражает, ты вроде как соглашаешься с моей поправкой, но делаешь это тоном училки-зануды.

V>В вырожденном случае ПМ вообще никаких отличий от if, ес-но. Медитировать надо над невырожденным.

Медитируй — не медитируй, страшнее жопы (достижимой в if) там ничего не будет.
Re[56]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.10.12 12:44
Оценка:
Здравствуйте, samius, Вы писали:

I>>Ты чего то попутал. С какого бодуна штаты вдруг начнут экспортировать спецов ? Сам посмотри — чуть не все высокотехнологичные конторы, сконцентрированы в США.

S>С твоего бодуна. Если бы США готовило достаточное для своих нужд количество специалистов и плюс к тому бы импортировало, то им пришлось бы так же и экспортировать их. Либо топить своих специалистов как котят в унитазе.

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

I>>Производство можно и в китай отдать, а для спецов проще создать условия, что бы новые конторы плодились.

S>Спецов можно и в Индии/Украине прикармливать а себе оставить управление/маркетинг.

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

S>Но речь лишь о том что они выпускают спецов меньше чем могли бы проглотить. Потому твой пример с США идет лесом. Индия может быть твой идеал?


Отдыхай.

I>>Официально дать его можно. А вот выхлопа ждать вряд ли стоит. Невозможно школьные пробелы компенсировать принудиловкой да в короткий срок, если такое устроишь, будет прорыв в образовании, так что записывайся в очередь на Нобелевку И еще момент — сикп это вагон работы на стороне кафедры. Каким образом кафедра это потянет, если сейчас выпуск методички и то подвигом считается ?

S>Внезапно методичка уже есть. Да и кафедры, вобщем, привыкшие к тому что программа регулярно меняется. Перечень спецкурсов вообще меняется раз в 5 лет напрочь. Так что ты на кафедры тоже не наговаривай.

Поясняю простую мысль — кафедры в тех вузах которые ты называешь ПТУ способны максимум скудную методичку родить. Для сикп это вообще _ничего_.

I>>И откуда уверенность, что этого уровня владения достаточно для программирования ?

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

Да очень просто — человек уже пошел в сантехники, т.к. другое не сложилось. Есть, теоретически, шанс, что этот сантехник ошибся в выборе и на самом деле у него худо-бедно прокачано абстрактное мышление, но этими шансами можно пренебречь.

I>>Вобще говоря ты прав — что бы ИТ-специалисты не уезжали за границу, нужно всего навсего перестать их готовить, утечка мозгов внезапно остановится.

S>Или готовить таких, что звать перестанут.

Это одно и то же — похоронить образование. Это и есть твое предложение ?

I>>Вышка нужна любому инженеру. А ты предлагаешь не просто ввести программуху, она уже давно введена, а тупо задрать планку не понятно на каком основании.

S>Куда задрать? Сикп не просит математики выше 5-го класса. Ну или там не помню, метод Ньютона в каком классе проходят. Даже если не пройден, в том же сикпе его и разжовывают.

В 5м классе, повторяю еще раз, только начинают давать те вещи, которые понадобятся при обучении программированию. Внимание, повторяю в который раз — 5й класс это тоьлко начало !!!

Сикп требует не математики выше 5го класса, а уровня прокачки этой математики до уровня рефлексов. Все что ты делаешь в школе, грубо говоря есть обучение символьному мышлениею, т.е. записать задачу в символах, решить и применить это решение к исходной задаче. Задачки при этом довольно примитивные, назвать их математикой можно только с большой натяжкой.
При этом, полностью этой математикой овладевают примерно к окончанию школы, и то, совсем небольшая часть людей.

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

Если ты с этим не согласен — вперёд, обучай детей программированию с 5го класса и показывай результаты и становись в очередь за нобелевкой.

Раньше тут выбегал Синклер и доказывал что это именно я предлагаю давать всем детям программирование в 5м классе.

I>>Мой ответ был про симптоп а не про точный диагноз Ты в курсе, что это разные вещи ? Попробуй ответить на мой вопрос и тебе все станет ясно.

S>Что за вопрос?

А посмотри в контекст, мне лень для тебя разжевывать.
Re[57]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 22.10.12 13:39
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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


Я уловил другую твою мысль о том что вузы в штатах полностью покрывают их потребности. Ее и опровергаю. Но тут подвернулась еще одна, видимо новые рабочие места создаются только в штатах, но никак ни на пост СССР. Или я опять что-то не понял в твоей теории?

S>>Спецов можно и в Индии/Украине прикармливать а себе оставить управление/маркетинг.


I>Не получится в общем случае. Для большинства самых сложных, важных и денежных проектов команда нужна вся и вместе.

И что?

S>>Но речь лишь о том что они выпускают спецов меньше чем могли бы проглотить. Потому твой пример с США идет лесом. Индия может быть твой идеал?


I>Отдыхай.

Спасибо за заботу, я уже с новыми силами.

S>>Внезапно методичка уже есть. Да и кафедры, вобщем, привыкшие к тому что программа регулярно меняется. Перечень спецкурсов вообще меняется раз в 5 лет напрочь. Так что ты на кафедры тоже не наговаривай.


I>Поясняю простую мысль — кафедры в тех вузах которые ты называешь ПТУ способны максимум скудную методичку родить. Для сикп это вообще _ничего_.

Поясняю еще более простую мысль. РОЖАТЬ НЕ НАДО.

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


I>Да очень просто — человек уже пошел в сантехники, т.к. другое не сложилось. Есть, теоретически, шанс, что этот сантехник ошибся в выборе и на самом деле у него худо-бедно прокачано абстрактное мышление, но этими шансами можно пренебречь.

Сантехник это не диагноз и не каста, что б ты знал. Это всего лишь специальность. Не надо ставить клеймо на человеке на основе его специальности.

S>>Или готовить таких, что звать перестанут.


I>Это одно и то же — похоронить образование. Это и есть твое предложение ?

Для тех, кто невнимательно читает, повторю. Это было мое предположение о том, чем занимается министерство образования.

S>>Куда задрать? Сикп не просит математики выше 5-го класса. Ну или там не помню, метод Ньютона в каком классе проходят. Даже если не пройден, в том же сикпе его и разжовывают.


I>В 5м классе, повторяю еще раз, только начинают давать те вещи, которые понадобятся при обучении программированию. Внимание, повторяю в который раз — 5й класс это тоьлко начало !!!

Повторю еще раз. Я не предлагаю давать сикп в 5м классе. Давай уже закроем эту тему. Это ТЫ предлагаешь давать сикп в 5м классе. Я возражаю.

I>Сикп требует не математики выше 5го класса, а уровня прокачки этой математики до уровня рефлексов. Все что ты делаешь в школе, грубо говоря есть обучение символьному мышлениею, т.е. записать задачу в символах, решить и применить это решение к исходной задаче. Задачки при этом довольно примитивные, назвать их математикой можно только с большой натяжкой.

I>При этом, полностью этой математикой овладевают примерно к окончанию школы, и то, совсем небольшая часть людей.
Значительная часть людей программу школы осваивают. А те, кто выходит со справкой вместо аттестата, меня мало интересуют.

I>Тебе, вероятно, невдомёк, но раньше 16 лет у ребенка мышление еще не сформировано полностью, при чем не сформировано именно то, чем пользуется программист как и любой инженер как и вообще любой специалист умственного труда — операционное мышление. До 16 лет его просто нет по большому счету.

Нет невдомек. В 14 я уже владел в значительной мере программированием на МК-61.

I>Если ты с этим не согласен — вперёд, обучай детей программированию с 5го класса и показывай результаты и становись в очередь за нобелевкой.

Еще раз. Это ТВОИ идеи обучать программированию с 5-го класса. Никто кроме тебя на форуме об этом не говорит.

I>Раньше тут выбегал Синклер и доказывал что это именно я предлагаю давать всем детям программирование в 5м классе.

А что, разве это не очевидно? Именно ты, да-да.

S>>Что за вопрос?


I>А посмотри в контекст, мне лень для тебя разжевывать.

А мне лень для тебя смотреть в контекст
Re[58]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.10.12 14:22
Оценка:
Здравствуйте, samius, Вы писали:

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


S>Я уловил другую твою мысль о том что вузы в штатах полностью покрывают их потребности.


"ощутимый выхлоп на общем фоне"
Как же ты любишь передёргивать

>Ее и опровергаю. Но тут подвернулась еще одна, видимо новые рабочие места создаются только в штатах, но никак ни на пост СССР. Или я опять что-то не понял в твоей теории?


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

I>>Не получится в общем случае. Для большинства самых сложных, важных и денежных проектов команда нужна вся и вместе.

S>И что?

Это значит, что экспортировать специалистов крайне не выгодно, а выгодно создавать условия, что бы создавались новые рабочие места. Если в раткосрочной перспективе система образования не справится, что очевидно, то есть выход — импорт.

I>>Поясняю простую мысль — кафедры в тех вузах которые ты называешь ПТУ способны максимум скудную методичку родить. Для сикп это вообще _ничего_.

S>Поясняю еще более простую мысль. РОЖАТЬ НЕ НАДО.

Ну да, сикп сам заработает, ага. Эдакая "невидимая рука" наведет порядок в вузе, создаст всю инфраструктуру и выстроит процесс. Посмотри старые курсы по СИКП, там вроде понятно, что кафедре надо приложить вагон усилий, что бы это работало. Кафедры в тех вузах, про которые мы говорим, на такое не способны. У них сил еле на методички хватает, а это для сикп вообще 0.

I>>Да очень просто — человек уже пошел в сантехники, т.к. другое не сложилось. Есть, теоретически, шанс, что этот сантехник ошибся в выборе и на самом деле у него худо-бедно прокачано абстрактное мышление, но этими шансами можно пренебречь.

S>Сантехник это не диагноз и не каста, что б ты знал. Это всего лишь специальность. Не надо ставить клеймо на человеке на основе его специальности.

Сантехник это просто результат особенностей мышления, если отбросить социальные факторы как безработица и алкоголизм.

I>>Это одно и то же — похоронить образование. Это и есть твое предложение ?

S>Для тех, кто невнимательно читает, повторю. Это было мое предположение о том, чем занимается министерство образования.

Ну ладно, ты отмазался

I>>В 5м классе, повторяю еще раз, только начинают давать те вещи, которые понадобятся при обучении программированию. Внимание, повторяю в который раз — 5й класс это тоьлко начало !!!

S>Повторю еще раз. Я не предлагаю давать сикп в 5м классе. Давай уже закроем эту тему. Это ТЫ предлагаешь давать сикп в 5м классе. Я возражаю.

Я тебе объясняю что твои рассуждения про 5й класс вообще бред вне категорий

I>>Сикп требует не математики выше 5го класса, а уровня прокачки этой математики до уровня рефлексов. Все что ты делаешь в школе, грубо говоря есть обучение символьному мышлениею, т.е. записать задачу в символах, решить и применить это решение к исходной задаче. Задачки при этом довольно примитивные, назвать их математикой можно только с большой натяжкой.

I>>При этом, полностью этой математикой овладевают примерно к окончанию школы, и то, совсем небольшая часть людей.
S>Значительная часть людей программу школы осваивают. А те, кто выходит со справкой вместо аттестата, меня мало интересуют.

Эта "значительная часть" всего процентов 10, а из них только каждый 10й может работать в ИТ.

I>>Тебе, вероятно, невдомёк, но раньше 16 лет у ребенка мышление еще не сформировано полностью, при чем не сформировано именно то, чем пользуется программист как и любой инженер как и вообще любой специалист умственного труда — операционное мышление. До 16 лет его просто нет по большому счету.

S>Нет невдомек. В 14 я уже владел в значительной мере программированием на МК-61.

По рецептам + решение тривиальных задач.

I>>Если ты с этим не согласен — вперёд, обучай детей программированию с 5го класса и показывай результаты и становись в очередь за нобелевкой.

S>Еще раз. Это ТВОИ идеи обучать программированию с 5-го класса. Никто кроме тебя на форуме об этом не говорит.

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

I>>Раньше тут выбегал Синклер и доказывал что это именно я предлагаю давать всем детям программирование в 5м классе.

S>А что, разве это не очевидно? Именно ты, да-да.

Это сарказм. Если такое слово для тебя с Синклером в новинку, то это не ко мне.
Re[44]: Императивное программирование
От: vdimas Россия  
Дата: 22.10.12 18:38
Оценка:
Здравствуйте, samius, Вы писали:

V>>Ну дык оно в силе. См. выделенное очень внимательно... настолько внимательно, насколько сможешь.

S>Увы мне тебя нечем порадовать. Ты даже haskell считаешь СП, чего уж говорить о первых ФП-языках.

Блин, до брехни скатываться не стоило. Покажи, где я считаю Хаскель СП? Я лишь высказываюсь относительно нечистых конструкций, вшитых в этот язык (в современный его вариант и в его расширения). А первые ФП-языки действительно являются классическими СП-языками, со всеми знакомыми тебе императивными циклами, ветвлениями, переменными и прочим. От ФП там только ФВП. Поэтому, тезис о том, что ФП произошло от СП ес-но в силе. Твоему Хаскелю в его нынешнем виде дай бог десяток лет или меньше, так что заканчивай во всех этих спорах, кто от кого произошел, приводить его в пример.

V>>Я привел тебе именно такие примеры.

S>Да нет, не привел. Либо ты не понял, что я от тебя хочу, либо кривляешься.

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

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

S>Это у тебя серьезные проблемы. Я с тебя просил вот это
S>http://en.wikipedia.org/wiki/Pure_function#Pure_expressions

Я знаю, что ты у меня спросил. Жаль что ты не знаешь. Читай там же:

Pure expressions are often referred to as being referentially transparent.

Я тебе это показал.

S>Извини что стейтментами назвал, но if/loop/sequence не работают с выражениями.


Похрен. Я тебе скопировал из твоей собственной ссылки фразу, которая ключевая дял понимания происходящего.



V>>>>Специально расписал на промежуточных мутабельных переменных, чтобы показать, что мутабельность не значит отсутствия чистоты вычислений. Я тебе ссылку на определение чистоты вычислений уже давал, помнится.

S>>>Печально что ты не смог применить определение к ветке if-а.

V>>Печально, что ты не понимаешь такого простого и одновременно такого ёмкого определения.

V>>Помочь разобрать его по шагам применительно к моим примерам? Выбирай любуую ветку if любого примера — я поясню происходящее.
S>В детский сад со своими примерами. Это не то, что я просил.

Именно то. Просто налицо непонимание св-в чистоты вычислений.

V>>Возьми для примера Немерле. Там имутабельные переменные, но на них выражается вычислительный процесс явным образом. То бишь, тот же самый императив.

S>Ты не понимаешь, что такое императив. Походу не справился с определением.

Я же сказал — курить теорию автоматов. Без неё понимание императива нереально.


V>>Ты просто убежал в очередной раз. Заканчивай уже бегать. Я привел примеры, давай их разбирать. Я пока еще не воткнул, в чём именно у тебя сложности с их пониманием. Насчет "чистых веток if" — это какой-то бред, ведь в императиве эти ветки не могут быть исполнены в отрыве от контекста. То бишь, чистота веток напрямую зависит от чистоты контекста. Если контекст детерминирован относительно потока вычисления, то ветки if автоматом детерминированы, если исполняются в том же потоке.

S>см pure expression

Сам смотри внимательней. И заканчивай ты уже этот пинг-понг пустыми постами. Возьми за труд хоть немного помедитировать над ответными аргументами. Все входы и выходы уже даны. См. мой предыдущий пост.

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

S>Никуда я не забегаю, ты мне эти примеры пишешь уже второй месяц.

Дык, тем хуже для тебя.
Вопросы на засыпку:
— что я имел ввиду под "контекстом вычислений" в этом абзаце?
— при чем тут детерминированность и куда она может пропасть в императиве?
— приведи пример пропадания детерминированности?
— если справишься с пред. пунктом, попробуй натянуть изобретенный пример(ы) на любой из моих. Получилось?

Если пройдешь этот квест, поймешь о чем речь.


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

S>Как бы там ни было, это не аргумент

Это я показывал, что спекулятивное переупорядочивание выполняется только для тех вычислений, которые и так будут выполнены. В отличие от обсуждаемого переупорядочивания на if.


V>>Да, её нет при операциях с вырожденными значениями алг.тд. В невырожденном случае — всегда.

S>Меня поражает, ты вроде как соглашаешься с моей поправкой, но делаешь это тоном училки-зануды.

Да какая нафик твоя поправка. Читай оригинал еще раз внимательнее:

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


Твою поправку (якобы поправку) я выделил. Всё было сказано сразу.

V>>В вырожденном случае ПМ вообще никаких отличий от if, ес-но. Медитировать надо над невырожденным.

S>Медитируй — не медитируй, страшнее жопы (достижимой в if) там ничего не будет.

А зря, помедитировать стоило бы. Если в if жопа может быть как результат каких-то затратных вычислений (иначе зачем бы параллелить), то в случае распаковки значений на ПМ получаем жопу как аргумент вычислений еще до их начала. А факт игнорирования аргумента (куда может придти жопа) должен обнаруживаться еще на этапе бета-редукции (у нас же детерминированные вычисления). В общем, если после бета-редукции таки осталась зависимость от жопы, то смысла продолжать вычисления в 99% нет. Остальные 1% я даю как погрешность, связанную с недостаточной реализацией бета-редукции. Хотя, в идеальном абстрактном мире, о котором шла речь в этих фантазиях, и бета-редукция должна быть идеальной. )))
Re[59]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 23.10.12 23:25
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Я уловил другую твою мысль о том что вузы в штатах полностью покрывают их потребности.


I>"ощутимый выхлоп на общем фоне"

I>Как же ты любишь передёргивать
Ладно, слово "ощутимый" можно трактовать по-разному.

>>Ее и опровергаю. Но тут подвернулась еще одна, видимо новые рабочие места создаются только в штатах, но никак ни на пост СССР. Или я опять что-то не понял в твоей теории?


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

Ну дак они их и создают в оффшорах. У меня множество знакомых работает именно так.

I>>>Не получится в общем случае. Для большинства самых сложных, важных и денежных проектов команда нужна вся и вместе.

S>>И что?

I>Это значит, что экспортировать специалистов крайне не выгодно, а выгодно создавать условия, что бы создавались новые рабочие места. Если в раткосрочной перспективе система образования не справится, что очевидно, то есть выход — импорт.

Мы уже были тут. Очевидно что их система образования излишек специалистов не выпускает и потребности штатов покрываются как их специалистами, так импортными, еще и в оффшор толпа проектов улетает.

S>>Поясняю еще более простую мысль. РОЖАТЬ НЕ НАДО.


I>Ну да, сикп сам заработает, ага. Эдакая "невидимая рука" наведет порядок в вузе, создаст всю инфраструктуру и выстроит процесс. Посмотри старые курсы по СИКП, там вроде понятно, что кафедре надо приложить вагон усилий, что бы это работало. Кафедры в тех вузах, про которые мы говорим, на такое не способны. У них сил еле на методички хватает, а это для сикп вообще 0.

Ты все еще про ПТУ? Завязывай уже.

S>>Сантехник это не диагноз и не каста, что б ты знал. Это всего лишь специальность. Не надо ставить клеймо на человеке на основе его специальности.


I>Сантехник это просто результат особенностей мышления, если отбросить социальные факторы как безработица и алкоголизм.

ну а если факторы не отбрасывать, то среди сантехников несложно найти докторов наук.

S>>Повторю еще раз. Я не предлагаю давать сикп в 5м классе. Давай уже закроем эту тему. Это ТЫ предлагаешь давать сикп в 5м классе. Я возражаю.


I>Я тебе объясняю что твои рассуждения про 5й класс вообще бред вне категорий

аргументы будут?

S>>Значительная часть людей программу школы осваивают. А те, кто выходит со справкой вместо аттестата, меня мало интересуют.


I>Эта "значительная часть" всего процентов 10

у вас 90% выпускников оканчивает школу со справкой? Жесть.
I>а из них только каждый 10й может работать в ИТ.
То есть уже 1 из 100...

S>>Нет невдомек. В 14 я уже владел в значительной мере программированием на МК-61.


I>По рецептам + решение тривиальных задач.

Не, ну ты же всегда можешь сказать что я всю жизнь решаю тривиальные задачи по рецептам. Потому это не аргумент. А потом, когда мне было 14, из рецептов ничего кроме инструкции не было. Гугля тоже че-та не было. И "МК-61 для чайников" тоже. Ну это так, между делом.

S>>Еще раз. Это ТВОИ идеи обучать программированию с 5-го класса. Никто кроме тебя на форуме об этом не говорит.


I>Нет, не мои. Ты же утверждаешь, что что все необходимое есть уже в 5м классе, а я говорю что это ахинея.

То что есть в 5м классе можно посмотреть по программе, а то что ты говоришь — ты многое можешь говорить. Если подтвердить нечем, кроме того что это говоришь ты, который 1 из 100, то говорить не о чем.

S>>А что, разве это не очевидно? Именно ты, да-да.


I>Это сарказм. Если такое слово для тебя с Синклером в новинку, то это не ко мне.

Тебя походу с сарказмом настолько заело, что ты уже забываешь, что это всего лишь твой сарказм, а не наши с Синклером идеи. Заведи тему и спорь там со своим сарказмом.
Re[45]: Императивное программирование
От: artelk  
Дата: 24.10.12 06:28
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Блин, до брехни скатываться не стоило. Покажи, где я считаю Хаскель СП? Я лишь высказываюсь относительно нечистых конструкций, вшитых в этот язык (в современный его вариант и в его расширения). А первые ФП-языки действительно являются классическими СП-языками, со всеми знакомыми тебе императивными циклами, ветвлениями, переменными и прочим. От ФП там только ФВП. Поэтому, тезис о том, что ФП произошло от СП ес-но в силе. Твоему Хаскелю в его нынешнем виде дай бог десяток лет или меньше, так что заканчивай во всех этих спорах, кто от кого произошел, приводить его в пример.

Выглядит как вариация на тему "Post hoc, ergo propter hoc"
Re[46]: Императивное программирование
От: vdimas Россия  
Дата: 24.10.12 08:49
Оценка:
Здравствуйте, samius, Вы писали:

V>>Похрен. Я тебе скопировал из твоей собственной ссылки фразу, которая ключевая дял понимания происходящего.

S>Ты этим меня хочешь убедить что присваивание легально в pure-expression?

По-моему, ты уже тупо троллишь... Я специально тебе показываю, что на мутабельных операциях можно получать pure-functions и прямо об этом говорю.
Абсолютно нет никакого дела до твоих pure-expressions, ими можно смело подтереться. Почему? Хотя бы потому, что pure-functions и pure-expressions — никак не зависят одно от другого от другого. Нечистые ф-ии могут включать чистые выражения и наборот, чистые ф-ии могут целиком состоять из нечистых выражений. Так понятно?

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

V>>Именно то. Просто налицо непонимание св-в чистоты вычислений.

S>Демонстрируешь его ты

Это уже какое-то гы-гы. )))
Кароч, если по интернету ходить не умеешь, будем копировать интернет прямо сюда:

In computer programming, a function may be described as pure if both these statements about the function hold:
1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

The result value need not depend on all (or any) of the argument values. However, it must depend on nothing other than the argument values.


Т.е. ты не понимаешь ни (1), ни (2), ни важного отличия ф-ий от выражений (выделено болдом).

V>>Я же сказал — курить теорию автоматов. Без неё понимание императива нереально.

S>Мне твое "я же сказал" не упирается.

А ну да, Баба-Яга против. Ради бога.


V>>Сам смотри внимательней. И заканчивай ты уже этот пинг-понг пустыми постами. Возьми за труд хоть немного помедитировать над ответными аргументами. Все входы и выходы уже даны. См. мой предыдущий пост.

S>Заканчивай свой пинг-понг со своими кури, медитируй, я же сказал и т.п. Аргументов я там не увидел. Увидел непонимание. И здесь опять.

Дык, аргументы, сниппеты, соответствующие сниппетам определения — всё есть. У тебя — ничего, кроме заезженой пластинки "Баба-Яга против!".
Даже есть дополнения и замечения, что целью является не чистота ни разу, а ссылочная прозрачность. Но выделенное явно запредельная сложность, т.к. ты пока не понимаешь отличие чистых вычислений (лямбд и ф-ий в т.ч.) от устоявшегося мема Purely functional.

Purely functional is a term in computing used to describe algorithms, data structures or programming languages that exclude destructive modifications (updates). According to this restriction, variables are used in a mathematical sense, with identifiers referring to immutable, persistent values.


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

ИМХО, ты всё время забываешь, что ФП-парадигма — это сугубо практическая парадигма, которая работает в условиях некоторых ограничений (см приведенное определение). И не имеет никакого отношения ни к ссылочной прозрачности, ни к чистоте вычислений. Оно является является лишь одним из способов достижения оных. Но никак не подменяет их собой. Вот в этом у тебя упор, бо ты поторопимшись ставишь знак тождества там, где всего-лишь наличиствует частное следствие.


V>>Вопросы на засыпку:

V>>- что я имел ввиду под "контекстом вычислений" в этом абзаце?
S>Да фиг тебя уже знает
V>>- при чем тут детерминированность и куда она может пропасть в императиве?
S>И причем тут детерминированность? Опять расписываешься в непонимании...

Вооот она, рыба моей мечты. )))
Вопрос-то на мильён $$.
При чем тут детерминированность, дествительно?

Ответ простой — это единственная цель, которую можно обсуждать. Всё остальное стоит уровнем гораздо ниже и является ср-вом, не более. В т.ч. ФП-парадигма является лишь ср-вом достижения этой цели. Угу, более никакой цели у ФП-парадигмы НЕТ. Вот причем тут детерминированность.

Детерминированность является непременным условием для ссылочной прозрачности.
В общем, сорри, но подкину еще дровишек для медитации:

Referential transparency and referential opaqueness are properties of parts of computer programs. An expression is said to be referentially transparent if it can be replaced with its value without changing the behavior of a program (in other words, yielding a program that has the same effects and output on the same input). The opposite term is referential opaqueness.

While in mathematics all function applications are referentially transparent, in programming this is not always the case. The importance of referential transparency is that it allows the programmer and the compiler to reason about program behavior.


Всё обсуждаемое нам нужно исключительно для того (см. выделенное), чтобы самим быть уверенными в том, как работают наши собственные программы. "Чистая" ФП-парадигма предоставляет нам именно такой инструмент. А я лишь показываю (уже не первый раз), что этот инструмент ни разу не единственный.

S>Если что, то о потоках ты не со мной разговаривал.


Недетерминированность достигается и безо-всяких потоков через неявные связи, то бишь через side-effects. Side-effects — это скрытое влияние программных компонент друг на друга или общение с внешним (недетерминированным) миром.


V>>- приведи пример пропадания детерминированности?

S>ReadLine
V>>- если справишься с пред. пунктом, попробуй натянуть изобретенный пример(ы) на любой из моих. Получилось?
S>Получилось, только я же просил pure-expression-ы.

Увы, натянуть на мои примеры не получилось. И не получится. Бо в примерах описаны не "открытые" всевозможным "левым" контекстам выражения, а исключительно чистые ф-ии с явными зависимостями. Хотя и все до одной мутабельные унутре. А просить pure-expression-ы для императивного языка само по себе попахивает нубством, не находишь?


V>>Это я показывал, что спекулятивное переупорядочивание выполняется только для тех вычислений, которые и так будут выполнены. В отличие от обсуждаемого переупорядочивания на if.

S>И это не становится аргументом

Становится аргументом при наличии потенциально-бесконечных вычислений в ветках ветвления. Не видишь, насколько это отличается от случая, когда спекулятивно выполняют вполне детерминированный объем вычислений? В общем, я уже рядом показал коллеге, как он в пылу спора забыл о той самой проблеме останова: http://www.rsdn.ru/forum/philosophy/4937235.1
Автор: vdimas
Дата: 22.10.12


Для нерекурсивного случая я уже давно согласился, что некритично (т.к. частный случай).


V>>Твою поправку (якобы поправку) я выделил. Всё было сказано сразу.

S>А я тебе сразу сказал что ничего ПМ нового не добавляет кроме дополнительных веток.

ОМГ.
Медленно. По слогам. Ветки if НЕ имеют зависимостей (аргументов) от предиката при if. Наоборот ветки, ПМ в общем случае зависят от аргумента ПМ. Какой случай я называю общим? — который невырожденный. А твоё "ничего нового не добавляется" истинно только для вырожденного случая.


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


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


S>и что теоретически время останется конечным но не факт что впишется во время существования вселенной.


Дык, ес-но. Проблема останова нерешаема именно из-за конечности вычислителя более не из-за чего. И да, в приведенных по ссылке обсуждениях я показал, почему время никак не остаётся конечным.


S>Твои попытки воззвать к оптимальности не отвергают возможности распараллеливания. Всё. Кури, медитируй, ставь себе 2.


Да похрен уже на оптимальность. Оно заведомо не работает на конечном вычислителе. А стоит внести детерминированность в "предпросмотр", то бишь сделать его заведомо конечным по суммарной мощности вычислений всех его веток, и ты опять получишь то самое упорядочивание, управляемое целевыми предикатами. То бишь, в этом случае нельзя будет говорить о том, что ветки вычислены РАНЬШЕ предиката. Они будут лишь запущены на вычисление раньше предиката. Прочувствуйте разницу, как говорится.
Re[46]: Императивное программирование
От: vdimas Россия  
Дата: 24.10.12 10:50
Оценка:
Здравствуйте, artelk, Вы писали:

V>>Блин, до брехни скатываться не стоило. Покажи, где я считаю Хаскель СП? Я лишь высказываюсь относительно нечистых конструкций, вшитых в этот язык (в современный его вариант и в его расширения). А первые ФП-языки действительно являются классическими СП-языками, со всеми знакомыми тебе императивными циклами, ветвлениями, переменными и прочим. От ФП там только ФВП. Поэтому, тезис о том, что ФП произошло от СП ес-но в силе. Твоему Хаскелю в его нынешнем виде дай бог десяток лет или меньше, так что заканчивай во всех этих спорах, кто от кого произошел, приводить его в пример.

A>Выглядит как вариация на тему "Post hoc, ergo propter hoc"

Не выглядит. Дело ведь не в том, что ФП появилось ПОСЛЕ СП (разве Лисп появился после???), а в том, что парадигма ФП появилась и устоялась в отрасли исключительно в виде СП-языков, в которых были добавлены ф-ии как первоклассные объекты + механизм ФВП (для реализации которых потребовались полноценные лямбды). Примеры этих языков я приводил: Lisp, APL, ML. От последнего произошли тоже кучи якобы функциональных, но на самом деле самых что ни на есть СП-языков, взять хотя бы OCaml.
Re[60]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.10.12 10:53
Оценка:
Здравствуйте, samius, Вы писали:

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

S>Ну дак они их и создают в оффшорах. У меня множество знакомых работает именно так.

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

I>>Это значит, что экспортировать специалистов крайне не выгодно, а выгодно создавать условия, что бы создавались новые рабочие места. Если в раткосрочной перспективе система образования не справится, что очевидно, то есть выход — импорт.

S>Мы уже были тут. Очевидно что их система образования излишек специалистов не выпускает и потребности штатов покрываются как их специалистами, так импортными, еще и в оффшор толпа проектов улетает.

А что, я где то говорил про излишек ?

I>>Ну да, сикп сам заработает, ага. Эдакая "невидимая рука" наведет порядок в вузе, создаст всю инфраструктуру и выстроит процесс. Посмотри старые курсы по СИКП, там вроде понятно, что кафедре надо приложить вагон усилий, что бы это работало. Кафедры в тех вузах, про которые мы говорим, на такое не способны. У них сил еле на методички хватает, а это для сикп вообще 0.

S>Ты все еще про ПТУ? Завязывай уже.

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

I>>Сантехник это просто результат особенностей мышления, если отбросить социальные факторы как безработица и алкоголизм.

S>ну а если факторы не отбрасывать, то среди сантехников несложно найти докторов наук.

Это только подтверждает мою идею

I>>Я тебе объясняю что твои рассуждения про 5й класс вообще бред вне категорий

S>аргументы будут?

Были, что бы их понять, начни с Р. Солсо "Когнитивная психология" и посмотри в работы Пиаже, Выготского, Лурии.

I>>Эта "значительная часть" всего процентов 10

S>у вас 90% выпускников оканчивает школу со справкой? Жесть.
I>>а из них только каждый 10й может работать в ИТ.
S>То есть уже 1 из 100...

Правильно. Отбор и так жосткий, а ты еще хочешь планку задрать неизвестно куда.

I>>По рецептам + решение тривиальных задач.

S>Не, ну ты же всегда можешь сказать что я всю жизнь решаю тривиальные задачи по рецептам. Потому это не аргумент. А потом, когда мне было 14, из рецептов ничего кроме инструкции не было. Гугля тоже че-та не было. И "МК-61 для чайников" тоже. Ну это так, между делом.

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

I>>Нет, не мои. Ты же утверждаешь, что что все необходимое есть уже в 5м классе, а я говорю что это ахинея.

S>То что есть в 5м классе можно посмотреть по программе, а то что ты говоришь — ты многое можешь говорить. Если подтвердить нечем, кроме того что это говоришь ты, который 1 из 100, то говорить не о чем.

У тебя странная позиция, вроде утверждаешь. Что в 5м классе есть все что нужно, но почему то признаешь, что давать программуху в 5м классе рановато.
Попробуй подумать над этим, обнаружишь противоречие.
Re[47]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.10.12 12:04
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Ты этим меня хочешь убедить что присваивание легально в pure-expression?


V>По-моему, ты уже тупо троллишь... Я специально тебе показываю, что на мутабельных операциях можно получать pure-functions и прямо об этом говорю.

Тупо троллишь ты. С тем что на мутабельных операциях можно получить pure-functions я даже не пытался с тобой спорить об этом. Я тебе твержу о том, что чистое выражение не имеет смысла в примитивах СП. А ты все про баню.

V>Абсолютно нет никакого дела до твоих pure-expressions, ими можно смело подтереться. Почему? Хотя бы потому, что pure-functions и pure-expressions — никак не зависят одно от другого от другого. Нечистые ф-ии могут включать чистые выражения и наборот, чистые ф-ии могут целиком состоять из нечистых выражений. Так понятно?

Иди смело подотрись. Дело всего лишь в том, что СП не умеет оперировать чистыми выражениями. Он тупо не годится для ФП без твоих любимых мутабельных операций. Да, на чистоте функции, в которой используются такие мутабельные операции, это может и не сказаться. Однако в ФП эти мутабельные костыли не нужны. Разница уже хотя бы в этом.

V>Ну и опять же, речь о чистоте вычислений, а эту чистоту оценивают по факту устройства программы целиком, а не по отдельным выражениям. Отдельные выражения НЕ являются законценной программной единицей хотя бы потому, что не не определяют явно своих зависимостей, в отличие от ф-ий.

что-что?
V> Я тебе уже который раз говорю, что св-ва выражений неотделимы от св-в окружающего видимого ими контекста.
Неотделимы, верно. Но чистое выражение не срет в окружающий видимый контекст (*)

V>>>Именно то. Просто налицо непонимание св-в чистоты вычислений.

S>>Демонстрируешь его ты

V>Это уже какое-то гы-гы. )))

V>Кароч, если по интернету ходить не умеешь, будем копировать интернет прямо сюда:
V>

V>In computer programming, a function may be described as pure if both these statements about the function hold:
V>1. The function always evaluates the same result value given the same argument value(s). The function result value cannot depend on any hidden information or state that may change as program execution proceeds or between different executions of the program, nor can it depend on any external input from I/O devices.
V>2. Evaluation of the result does not cause any semantically observable side effect or output, such as mutation of mutable objects or output to I/O devices.

V>The result value need not depend on all (or any) of the argument values. However, it must depend on nothing other than the argument values.


V>Т.е. ты не понимаешь ни (1), ни (2), ни важного отличия ф-ий от выражений (выделено болдом).

Если бы ты это понимал, то ты бы не утверждал о нечистоте if-а.

S>>Заканчивай свой пинг-понг со своими кури, медитируй, я же сказал и т.п. Аргументов я там не увидел. Увидел непонимание. И здесь опять.


V>Дык, аргументы, сниппеты, соответствующие сниппетам определения — всё есть. У тебя — ничего, кроме заезженой пластинки "Баба-Яга против!".

Нет, твои аргументы не аргументы, и ты демонстрируешь непонимание определений.

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

V>

V>Purely functional is a term in computing used to describe algorithms, data structures or programming languages that exclude destructive modifications (updates). According to this restriction, variables are used in a mathematical sense, with identifiers referring to immutable, persistent values.


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

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

V>ИМХО, ты всё время забываешь, что ФП-парадигма — это сугубо практическая парадигма, которая работает в условиях некоторых ограничений (см приведенное определение). И не имеет никакого отношения ни к ссылочной прозрачности, ни к чистоте вычислений. Оно является является лишь одним из способов достижения оных. Но никак не подменяет их собой. Вот в этом у тебя упор, бо ты поторопимшись ставишь знак тождества там, где всего-лишь наличиствует частное следствие.

Ты в упор не видишь мой упор. Мой упор в том, что СП без изменяемого состояния никуда. И даже если ты хочешь сделать на СП чистую функцию и тебе нужны последовательность/ветвление/цикл, то тебе придется вводить как минимум локальные состояния и изменять их.

V>>>Вопросы на засыпку:

V>>>- что я имел ввиду под "контекстом вычислений" в этом абзаце?
S>>Да фиг тебя уже знает
V>>>- при чем тут детерминированность и куда она может пропасть в императиве?
S>>И причем тут детерминированность? Опять расписываешься в непонимании...

V>Вооот она, рыба моей мечты. )))

V>Вопрос-то на мильён $$.
копейка
V>При чем тут детерминированность, дествительно?

V>Ответ простой — это единственная цель, которую можно обсуждать. Всё остальное стоит уровнем гораздо ниже и является ср-вом, не более. В т.ч. ФП-парадигма является лишь ср-вом достижения этой цели. Угу, более никакой цели у ФП-парадигмы НЕТ. Вот причем тут детерминированность.

Ты все попутал, как всегда. Детерминированность не имеет самоценности, ровно как и отсутствие побочных эффектов. Но без них не работает ФП, как ИП/СП не работает без состояния. В СП состояние тоже не является целью.

V>Детерминированность является непременным условием для ссылочной прозрачности.

Это верно
V>В общем, сорри, но подкину еще дровишек для медитации:
V>

V>Referential transparency and

Слушай, ничего нового ты не открываешь для меня. Эти определения уже затерты до дыр на этом форуме.

V>Всё обсуждаемое нам нужно исключительно для того (см. выделенное), чтобы самим быть уверенными в том, как работают наши собственные программы. "Чистая" ФП-парадигма предоставляет нам именно такой инструмент. А я лишь показываю (уже не первый раз), что этот инструмент ни разу не единственный.

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

S>>Если что, то о потоках ты не со мной разговаривал.


V>Недетерминированность достигается и безо-всяких потоков через неявные связи, то бишь через side-effects. Side-effects — это скрытое влияние программных компонент друг на друга или общение с внешним (недетерминированным) миром.

это известно без тебя.


V>>>- приведи пример пропадания детерминированности?

S>>ReadLine
V>>>- если справишься с пред. пунктом, попробуй натянуть изобретенный пример(ы) на любой из моих. Получилось?
S>>Получилось, только я же просил pure-expression-ы.

V>Увы, натянуть на мои примеры не получилось. И не получится. Бо в примерах описаны не "открытые" всевозможным "левым" контекстам выражения, а исключительно чистые ф-ии с явными зависимостями. Хотя и все до одной мутабельные унутре. А просить pure-expression-ы для императивного языка само по себе попахивает нубством, не находишь?

Я нахожу что нубством попахивает то, что тебе приходится объяснять разницу между СП и ФП на таких нубских примерах, хотя эта разница описана в определениях.

V>>>Это я показывал, что спекулятивное переупорядочивание выполняется только для тех вычислений, которые и так будут выполнены. В отличие от обсуждаемого переупорядочивания на if.

S>>И это не становится аргументом

V>Становится аргументом при наличии потенциально-бесконечных вычислений в ветках ветвления. Не видишь, насколько это отличается от случая, когда спекулятивно выполняют вполне детерминированный объем вычислений? В общем, я уже рядом показал коллеге, как он в пылу спора забыл о той самой проблеме останова: http://www.rsdn.ru/forum/philosophy/4937235.1
Автор: vdimas
Дата: 22.10.12

В сферической архитектуре проблемы остановки потока нет. И уж точно никакой проблемой останова не пахнет.

V>Для нерекурсивного случая я уже давно согласился, что некритично (т.к. частный случай).

ну хоть с чем-то ты согласился

V>>>Твою поправку (якобы поправку) я выделил. Всё было сказано сразу.

S>>А я тебе сразу сказал что ничего ПМ нового не добавляет кроме дополнительных веток.

V>ОМГ.

V>Медленно. По слогам. Ветки if НЕ имеют зависимостей (аргументов) от предиката при if. Наоборот ветки, ПМ в общем случае зависят от аргумента ПМ. Какой случай я называю общим? — который невырожденный. А твоё "ничего нового не добавляется" истинно только для вырожденного случая.
Ветки ПМ от аргумента ПМ зависят в ЧАСТНОМ случае. Ниужели у тебя проблемы даже с пониманием частного/общего?

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


V>Дык, для общего случая ПМ ты как раз резко сокращаешь класс вычислимых ф-ий. Почему? Потому что подаешь как аргумент еще невычесленное значение, которое можно представить разве что жопой. Мы же исходим из того, что аргумент ПМ еще не вычислен, так?

Никакое сокращение (даже резкое) не интересно в плане рассуждений о классе вычислимости "все вычислимые функции", потому как они либо вычислимы, либо нет. И между вычислимы и "резко вычислимы" нет никакой значимой разницы.

S>>и что теоретически время останется конечным но не факт что впишется во время существования вселенной.


V>Дык, ес-но. Проблема останова нерешаема именно из-за конечности вычислителя более не из-за чего. И да, в приведенных по ссылке обсуждениях я показал, почему время никак не остаётся конечным.

нет не показал.

S>>Твои попытки воззвать к оптимальности не отвергают возможности распараллеливания. Всё. Кури, медитируй, ставь себе 2.


V>Да похрен уже на оптимальность. Оно заведомо не работает на конечном вычислителе. А стоит внести детерминированность в "предпросмотр", то бишь сделать его заведомо конечным по суммарной мощности вычислений всех его веток, и ты опять получишь то самое упорядочивание, управляемое целевыми предикатами. То бишь, в этом случае нельзя будет говорить о том, что ветки вычислены РАНЬШЕ предиката. Они будут лишь запущены на вычисление раньше предиката. Прочувствуйте разницу, как говорится.

Это не имеет значения. Значение имеет лишь то, что последовательность условие->ветка может быть нарушена пусть даже в небольшом количестве сценариев. А вычислимость на конечном вычислителе (даже однопроцессорном) можно достичь ограничениями по времени и приоритетами.
Re[61]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.10.12 13:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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

S>>Ну дак они их и создают в оффшорах. У меня множество знакомых работает именно так.

I>Вынуждены создавать. При этом у себя в штатах проектов создают столько, что количетсво занятых в ИТ постоянно растет.

Надо же! А где не растет?

S>>Мы уже были тут. Очевидно что их система образования излишек специалистов не выпускает и потребности штатов покрываются как их специалистами, так импортными, еще и в оффшор толпа проектов улетает.


I>А что, я где то говорил про излишек ?

Я говорил

S>>Ты все еще про ПТУ? Завязывай уже.


I>Я про количество. Хочешь получить не только качественный, но и количественный результат — надо задействовать все вузы, иначе так и будет, когда три вуза выпускают толковы, еще пяток — посредственных и сотня выпускает мусор.

Количественный результат мы уже имеем.

I>>>Сантехник это просто результат особенностей мышления, если отбросить социальные факторы как безработица и алкоголизм.

S>>ну а если факторы не отбрасывать, то среди сантехников несложно найти докторов наук.

I>Это только подтверждает мою идею

Это не идея, это самовнушение

I>>>Я тебе объясняю что твои рассуждения про 5й класс вообще бред вне категорий

S>>аргументы будут?

I>Были, что бы их понять, начни с Р. Солсо "Когнитивная психология" и посмотри в работы Пиаже, Выготского, Лурии.

Я очень сильно не уверен в том что они свои работы посветили 5му классу общеобразовательной школы или СИКП-у.

S>>То есть уже 1 из 100...


I>Правильно. Отбор и так жосткий, а ты еще хочешь планку задрать неизвестно куда.

Да не, отбор далеко не такой жосткий. Это у тебя самомнение жосткое.

S>>Не, ну ты же всегда можешь сказать что я всю жизнь решаю тривиальные задачи по рецептам. Потому это не аргумент. А потом, когда мне было 14, из рецептов ничего кроме инструкции не было. Гугля тоже че-та не было. И "МК-61 для чайников" тоже. Ну это так, между делом.


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

А ты наверное программируешь сам без рецептов и подопечные твои тоже? Вкурили грамматику и пошли пилить в продакшн без единого примера вроде решения линейного уравнения? Ну-ну

I>У тебя странная позиция, вроде утверждаешь. Что в 5м классе есть все что нужно, но почему то признаешь, что давать программуху в 5м классе рановато.

I>Попробуй подумать над этим, обнаружишь противоречие.
Программуху вообще — рановато. А маппить функцией точки из области определения (со scale/translate преобразованиями) — как бы уже не поздно было в 5-м то классе. Именно про это я говорил что в 5м классе есть все что нужно.
Re[48]: Императивное программирование
От: vdimas Россия  
Дата: 24.10.12 15:04
Оценка:
Здравствуйте, samius, Вы писали:

V>>По-моему, ты уже тупо троллишь... Я специально тебе показываю, что на мутабельных операциях можно получать pure-functions и прямо об этом говорю.

S>Тупо троллишь ты. С тем что на мутабельных операциях можно получить pure-functions я даже не пытался с тобой спорить об этом. Я тебе твержу о том, что чистое выражение не имеет смысла в примитивах СП. А ты все про баню.

ОМГ.
1. Имеет смысл, ес-но. Например в С/С++: тернарный оператор, оператор присваивания, оператор "," (запятая) — все эти операторы имеют (могут иметь) значения. Т.е. многие вроде бы стейтменты легко сходят за выражения, даже если тип выражения — void. И да, ты можешь смело вместо if обсуждать тернарный оператор, бо он тоже допускает любые возвращаемые типы выражений своих веток, тот же void. Ууупс??? Забыл??? ))

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

Просто смысла в этой клоунаде нет. Вместо пытаток в течении 10-ка постов выдавить из оппонента "правильный" ответ на провокационный вопрос можно было сразу выложить на стол все карты — что именно ты хотел услышать и что заготовил в кач-ве своего ответа?

Просто ситуация на на самом деле такова, что:
1. в императиве тоже полно чистых ф-ий и чистых конструкций.
2. лучшие оптимизаторы сегодня для императива, и эти оптимизаторы прекрасно сами видят все зависимости. Это тупым ФП-компиляторам зависимости надо указывать явно.
3. так что обсуждать стоит возможность подобного переупорядочивания скорее для императива, как следует из п. 1 и 2. Тем более, что ты довольствуешься самой малой возможностью (вероятностью) подобных переупорядочиваний. Дык, в императиве этих возможностей на сегодня реально больше, чем в ФП.

(это был исчерпывающий ответ так же на остальное скипнутое, см. хотя бы последний свой абзац из скипнутого)
Re[62]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 24.10.12 15:06
Оценка:
Здравствуйте, samius, Вы писали:

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

S>>>Ну дак они их и создают в оффшорах. У меня множество знакомых работает именно так.

I>>Вынуждены создавать. При этом у себя в штатах проектов создают столько, что количетсво занятых в ИТ постоянно растет.

S>Надо же! А где не растет?

Мы про долю "своих" специалистов или просто потрепаться ? Определись.

I>>А что, я где то говорил про излишек ?

S>Я говорил

Вот ты и ищие его.

I>>Я про количество. Хочешь получить не только качественный, но и количественный результат — надо задействовать все вузы, иначе так и будет, когда три вуза выпускают толковы, еще пяток — посредственных и сотня выпускает мусор.

S>Количественный результат мы уже имеем.

Значит осталось самое малое — без значительного ухудшения этого результата улучшить качественную составляющую.

I>>Были, что бы их понять, начни с Р. Солсо "Когнитивная психология" и посмотри в работы Пиаже, Выготского, Лурии.

S>Я очень сильно не уверен в том что они свои работы посветили 5му классу общеобразовательной школы или СИКП-у.

Да, там нет ответа, можно ли давать программирование в 5м классе. Зато там рассказывается про мышление например.

I>>Правильно. Отбор и так жосткий, а ты еще хочешь планку задрать неизвестно куда.

S>Да не, отбор далеко не такой жосткий. Это у тебя самомнение жосткое.

Если в твоем кругу общения из двух человек, программистов 50%, то это вовсе не значит, что и по стране точно так же.

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

S>А ты наверное программируешь сам без рецептов и подопечные твои тоже? Вкурили грамматику и пошли пилить в продакшн без единого примера вроде решения линейного уравнения? Ну-ну

Мне снова коментировать твои передергивания и домыслы ?
Для школьника 14 лет рецепты и простейшие задачки это как максимум. То есть адаптация имеющихся решения и минимум декомпозиции. А для программиста, хотя бы новичка в продакшне, это вообще ничего, нужно обязательно владение декомпозицией.
Декомпозиция(а так же многое другое) это именно то, что появляется примерно в 16 лет, это т.н. операционое мышление, то есть "синтез-анализ", "композиция-декомпозиция", "абстракция-конкретизация".
Кое какие вещи школьники могут и раньше, но тольк кое что. Скажем, декомпозицию основаную на процедурных знаниях, могут уже раньше. Т.е. они могут скажем, рассказать, как нужно перетащить шкаф в другую комнату, что для этого необходимо и тд.

S>Программуху вообще — рановато. А маппить функцией точки из области определения (со scale/translate преобразованиями) — как бы уже не поздно было в 5-м то классе. Именно про это я говорил что в 5м классе есть все что нужно.


Правильно, рановато. А вот "мапить" школьники учатся до 11 класса включительно, а не внезапно, как по твоему, открывают перком в 5м классе.
Re[63]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 24.10.12 16:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Вынуждены создавать. При этом у себя в штатах проектов создают столько, что количетсво занятых в ИТ постоянно растет.

S>>Надо же! А где не растет?

I>Мы про долю "своих" специалистов или просто потрепаться ? Определись.

Даже если про долю "своих" специалистов, то полагаю что в России доля своих специалистов больше, чем в США своих.

I>>>А что, я где то говорил про излишек ?

S>>Я говорил

I>Вот ты и ищие его.

Я помню что говорил.

S>>Количественный результат мы уже имеем.


I>Значит осталось самое малое — без значительного ухудшения этого результата улучшить качественную составляющую.

Дай подумать.... Ты предлагаешь напрячь те самые кафедры, которые методичку родить не могут?

S>>Я очень сильно не уверен в том что они свои работы посветили 5му классу общеобразовательной школы или СИКП-у.


I>Да, там нет ответа, можно ли давать программирование в 5м классе. Зато там рассказывается про мышление например.

Что бы мыслить не нужны рассказы про мышление.

I>>>Правильно. Отбор и так жосткий, а ты еще хочешь планку задрать неизвестно куда.

S>>Да не, отбор далеко не такой жосткий. Это у тебя самомнение жосткое.

I>Если в твоем кругу общения из двух человек, программистов 50%, то это вовсе не значит, что и по стране точно так же.

Из того что у тебя на 100 знакомых лишь ты один работаешь в ИТ незначит что остальные тупее тебя и им принципиально в связи с особенностями мышления не понять твои заботы.

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

S>>А ты наверное программируешь сам без рецептов и подопечные твои тоже? Вкурили грамматику и пошли пилить в продакшн без единого примера вроде решения линейного уравнения? Ну-ну

I>Мне снова коментировать твои передергивания и домыслы ?

Тебе нужен мой запрет или разрешение? Валяй
I>Для школьника 14 лет рецепты и простейшие задачки это как максимум. То есть адаптация имеющихся решения и минимум декомпозиции. А для программиста, хотя бы новичка в продакшне, это вообще ничего, нужно обязательно владение декомпозицией.
I>Декомпозиция(а так же многое другое) это именно то, что появляется примерно в 16 лет, это т.н. операционое мышление, то есть "синтез-анализ", "композиция-декомпозиция", "абстракция-конкретизация".
I>Кое какие вещи школьники могут и раньше, но тольк кое что. Скажем, декомпозицию основаную на процедурных знаниях, могут уже раньше. Т.е. они могут скажем, рассказать, как нужно перетащить шкаф в другую комнату, что для этого необходимо и тд.
Боюсь тебя расстроить, но ни в 14 ни в 16 я не был знаком с твоей теорией. И даже сейчас не собираюсь с ней знакомиться, ибо считаю ее бредом. Конечно, вай-комбинатор я не изобретал, но вбить влет программу для построения графика функции с заданным шагом умел. Скажешь простейшая задачка? Для паскаля-да. А на калькуляторе с обратной польской — поди попробуй адаптируй какойнибудь рецепт из инструкции. Я сейчас-то очкую над такой задачей.

I>Правильно, рановато. А вот "мапить" школьники учатся до 11 класса включительно, а не внезапно, как по твоему, открывают перком в 5м классе.

Те что у вас учатся до 11 класса мапить у нас бы в 6-ой не перевелись.
Был в классе один такой, но у него реально учеба была не в первой десятке приоритетов. В 6-ой чудом перевелся на второй год, потом в ПТУ. У вас чо, такое норма?
Re[50]: Императивное программирование
От: vdimas Россия  
Дата: 24.10.12 23:12
Оценка:
Здравствуйте, samius, Вы писали:

V>>>>По-моему, ты уже тупо троллишь... Я специально тебе показываю, что на мутабельных операциях можно получать pure-functions и прямо об этом говорю.

S>>>Тупо троллишь ты. С тем что на мутабельных операциях можно получить pure-functions я даже не пытался с тобой спорить об этом. Я тебе твержу о том, что чистое выражение не имеет смысла в примитивах СП. А ты все про баню.

V>>ОМГ.

V>>1. Имеет смысл, ес-но. Например в С/С++: тернарный оператор, оператор присваивания, оператор "," (запятая) — все эти операторы имеют (могут иметь) значения. Т.е. многие вроде бы стейтменты легко сходят за выражения, даже если тип выражения — void. И да, ты можешь смело вместо if обсуждать тернарный оператор, бо он тоже допускает любые возвращаемые типы выражений своих веток, тот же void. Ууупс??? Забыл??? ))
S>Ты упустил из виду что возможности C/C++ очевидным образом выпирают из базиса СП. Такшта обсуждение тернарного оператора отменяется.

Ок, бери присваивание или запятую. )))

V>>2. Еще раз черным по белому — я знаю, что ты хотел у меня спросить. Но на подобные дешевые провокации не пойду всё-равно, даже при наличии п.1. и кучи вариантов как следствие этого пункта, вокруг которых вполне можно было бы пободаться (ветки-то вполне могут быть независимы даже в императиве, угу).

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

Сам кури. Что курить — я уже говорил. Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.


V>>Просто смысла в этой клоунаде нет. Вместо пытаток в течении 10-ка постов выдавить из оппонента "правильный" ответ на провокационный вопрос можно было сразу выложить на стол все карты — что именно ты хотел услышать и что заготовил в кач-ве своего ответа?

S>Я их сначала выложил, ты ничего не понял, а потом я из тебя ну точно не 10-ок постов (больше) выдавливал ответ на провокационный вопрос. В прошлом посте я опять открыл карты, но ты тут носишься со своей правотой, видимо пропустил.

Угу, и опять, видимо, пропустил...
Так не было ничего? ))

V>>Просто ситуация на на самом деле такова, что:

V>>1. в императиве тоже полно чистых ф-ий и чистых конструкций.
S>Я бы сказал что это достаточная экзотика для императива. Возможность так писать местами есть, да, согласен. Но полно — это ошибочная оценка.

Это нормальная оценка, см. сниппеты: http://www.rsdn.ru/forum/philosophy/4932310.1
Автор: vdimas
Дата: 17.10.12

В отсутствии оперирования глобальными/статическими переменными я бы дал оценку до 90% и выше для ситуаций обработки любых данных, видимых лишь из одного потока.


V>>2. лучшие оптимизаторы сегодня для императива, и эти оптимизаторы прекрасно сами видят все зависимости. Это тупым ФП-компиляторам зависимости надо указывать явно.

S>С оптимизаторами ты идешь лесом, объясняю который раз.

Коль обсуждали все эти переупорядочивания, то идешь сейчас ты.

V>>3. так что обсуждать стоит возможность подобного переупорядочивания скорее для императива, как следует из п. 1 и 2. Тем более, что ты довольствуешься самой малой возможностью (вероятностью) подобных переупорядочиваний. Дык, в императиве этих возможностей на сегодня реально больше, чем в ФП.

S>Увы, ты ошибаешься. Императив завязан на порядок побочными эффектами.

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

S>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.


Никоим образом не устремляюсь. В сниппетах показал — почему.

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

S>Исчерпывающим я его не считаю. Ты поскипал неудобные вещи и отмазался своими обычными заблуждениями.

)))
Re[51]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.10.12 00:37
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Ты упустил из виду что возможности C/C++ очевидным образом выпирают из базиса СП. Такшта обсуждение тернарного оператора отменяется.


V>Ок, бери присваивание или запятую. )))

Возвращаемое значение присваивания и запятой не распространится дальше ;/if/while если не положить его в переменную. Кроме того, в базисе СП нет ни слова про "возвращать значения". Базис СП опирается на стейтменты, суть которых — изменять состояние программы. А возвращать стейтменты ничего не обязаны.

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


V>Сам кури. Что курить — я уже говорил. Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.

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

V>Угу, и опять, видимо, пропустил...

V>Так не было ничего? ))
Экое у тебя избирательное внимание

S>>Я бы сказал что это достаточная экзотика для императива. Возможность так писать местами есть, да, согласен. Но полно — это ошибочная оценка.


V>Это нормальная оценка, см. сниппеты: http://www.rsdn.ru/forum/philosophy/4932310.1
Автор: vdimas
Дата: 17.10.12

V>В отсутствии оперирования глобальными/статическими переменными я бы дал оценку до 90% и выше для ситуаций обработки любых данных, видимых лишь из одного потока.
Во-первых ты забыл оперирование полями, во вторых отсутствие оперирования глобальными/статическими/экземплярными переменными для императива нетипично. Если в ФП такое оперирование сильно портит жизнь, то в ИП оно является фактически нормой. Так что, к чему ты собрался применять оценку до 90% — для меня неочевидно. Может быть для << 1% случаев, когда в программе действительно отсутствует оперирование глобальными и т.п. полями?

S>>С оптимизаторами ты идешь лесом, объясняю который раз.


V>Коль обсуждали все эти переупорядочивания, то идешь сейчас ты.

То что мы обсуждали переупорядочивания не делает оптимизаторы аргументом в пользу происхождения ФП от СП. Потому идти тебе.

V>>>3. так что обсуждать стоит возможность подобного переупорядочивания скорее для императива, как следует из п. 1 и 2. Тем более, что ты довольствуешься самой малой возможностью (вероятностью) подобных переупорядочиваний. Дык, в императиве этих возможностей на сегодня реально больше, чем в ФП.

S>>Увы, ты ошибаешься. Императив завязан на порядок побочными эффектами.

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

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

S>>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.


V>Никоим образом не устремляюсь. В сниппетах показал — почему.


И что же в них недетерминировано?
Re: Императивное программирование
От: LaptevVV Россия  
Дата: 25.10.12 07:31
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>А что насчет циклов for?

I> 1.Переменные
I> 2.Массивы
I> 3.Оператор if
I> 4.Команды перехода (goto или jump)
I>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.
Можно без массивов, операторов if и goto...

повторять 10 раз
что-то делаем

Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[64]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.10.12 10:30
Оценка:
Здравствуйте, samius, Вы писали:

I>>Мы про долю "своих" специалистов или просто потрепаться ? Определись.

S>Даже если про долю "своих" специалистов, то полагаю что в России доля своих специалистов больше, чем в США своих.

Проколупай дыру у себя в бензобаке — раз потечет, значит там излишек бензина...

I>>Значит осталось самое малое — без значительного ухудшения этого результата улучшить качественную составляющую.

S>Дай подумать.... Ты предлагаешь напрячь те самые кафедры, которые методичку родить не могут?

У тебя почему то улучшение результата всегда какой то напряг означет. Есть более эффективные методы. Напрягать ты сам предлагал, забыл ?

I>>Да, там нет ответа, можно ли давать программирование в 5м классе. Зато там рассказывается про мышление например.

S>Что бы мыслить не нужны рассказы про мышление.

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

I>>Если в твоем кругу общения из двух человек, программистов 50%, то это вовсе не значит, что и по стране точно так же.

S>Из того что у тебя на 100 знакомых лишь ты один работаешь в ИТ незначит что остальные тупее тебя и им принципиально в связи с особенностями мышления не понять твои заботы.

У меня на сотню знакомых почти все программисты или люди с ИТ-образованием Так что твои аллюзии мне не понятны.

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

S>Боюсь тебя расстроить, но ни в 14 ни в 16 я не был знаком с твоей теорией.

Это не моя теория.

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


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

I>>Правильно, рановато. А вот "мапить" школьники учатся до 11 класса включительно, а не внезапно, как по твоему, открывают перком в 5м классе.

S>Те что у вас учатся до 11 класса мапить у нас бы в 6-ой не перевелись.

"Мапить" включает в себя и интегралы и производные и много чего еще. Поверю на слово — ты все это умел в 5м классе в возрасте 14ти лет Не подскажешь, как тебе это удалось ?
Re[65]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.10.12 10:51
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Проколупай дыру у себя в бензобаке — раз потечет, значит там излишек бензина...

А, остряк типа? Тут поржать что ли надо?

S>>Дай подумать.... Ты предлагаешь напрячь те самые кафедры, которые методичку родить не могут?


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

Ты же убеждал что там нечего напрягать, забыл?

S>>Что бы мыслить не нужны рассказы про мышление.


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

Мне это не нужно, я не собираюсь давать программуху в 5м классе общеобразовательной школы.

I>У меня на сотню знакомых почти все программисты или люди с ИТ-образованием Так что твои аллюзии мне не понятны.

Тогда мне твои непонятны про 10% из 10%.

S>>Боюсь тебя расстроить, но ни в 14 ни в 16 я не был знаком с твоей теорией.


I>Это не моя теория.

Это ничего не меняет

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


I>Это мелочевочка. В книге, кстати говоря, был пример очень похожий. А твоё "очкую" говорит о том, что тогда эта программа показалась тебе сложной , при чем напугала тебя настолько, что ты до сих пор "очкуешь". Реально там были подпрограммы, организуешь простейший цикл, что было в рецепте, вызываешь подпрограмму, что было в рецепте, и все. Ну разве что надо было шаг выполнить, что снова было в рецепте. И представь, все это укладывалось в 105 ячеек памяти команд/данных.

Вах, разобрал по косточкам... Ну да, теперь мелочевка.
З.Ы. Про 105 ячеек не напугал нисколько, реально их там работало не больше 98и, а дальше мусор гулял.

S>>Те что у вас учатся до 11 класса мапить у нас бы в 6-ой не перевелись.


I>"Мапить" включает в себя и интегралы и производные и много чего еще. Поверю на слово — ты все это умел в 5м классе в возрасте 14ти лет Не подскажешь, как тебе это удалось ?

Аппликативные функторы твое "много чего еще" не включает?
Re[66]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.10.12 11:27
Оценка:
Здравствуйте, samius, Вы писали:

I>>Проколупай дыру у себя в бензобаке — раз потечет, значит там излишек бензина...

S>А, остряк типа? Тут поржать что ли надо?

А чо, мне кажется отличный аргумент в твою пользу

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

S>Ты же убеждал что там нечего напрягать, забыл?

Именно потому и нет смысла напрягать, следовательно надо действовать другми методами. Если на результат насрать — можно и понапрягать. Ну, еще переименовать одно в другое, ВУЗ в ПТУ, вот как медведев милицию в полицию переделал.

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

S>Мне это не нужно, я не собираюсь давать программуху в 5м классе общеобразовательной школы.

А по моему ты продолжаешь утверждать, что в 5м классе дается все необходимое для программухи.

I>>У меня на сотню знакомых почти все программисты или люди с ИТ-образованием Так что твои аллюзии мне не понятны.

S>Тогда мне твои непонятны про 10% из 10%.

Мне уже поднадоело объяснять.

I>>Это мелочевочка. В книге, кстати говоря, был пример очень похожий. А твоё "очкую" говорит о том, что тогда эта программа показалась тебе сложной , при чем напугала тебя настолько, что ты до сих пор "очкуешь". Реально там были подпрограммы, организуешь простейший цикл, что было в рецепте, вызываешь подпрограмму, что было в рецепте, и все. Ну разве что надо было шаг выполнить, что снова было в рецепте. И представь, все это укладывалось в 105 ячеек памяти команд/данных.

S>Вах, разобрал по косточкам... Ну да, теперь мелочевка.
S>З.Ы. Про 105 ячеек не напугал нисколько, реально их там работало не больше 98и, а дальше мусор гулял.

Наверное это специально для тебя сделали, а то у меня было 105 да еще 15 регистров памяти.

I>>"Мапить" включает в себя и интегралы и производные и много чего еще. Поверю на слово — ты все это умел в 5м классе в возрасте 14ти лет Не подскажешь, как тебе это удалось ?

S>Аппликативные функторы твое "много чего еще" не включает?

А если подумать ? У меня вопрос, кстати, а чего ты в 14 лет в пятом классе делал ?
Re[67]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.10.12 11:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Проколупай дыру у себя в бензобаке — раз потечет, значит там излишек бензина...

S>>А, остряк типа? Тут поржать что ли надо?

I>А чо, мне кажется отличный аргумент в твою пользу

Проколупай дыру у себя в черепе — этот мне нравится.

S>>Ты же убеждал что там нечего напрягать, забыл?


I>Именно потому и нет смысла напрягать, следовательно надо действовать другми методами. Если на результат насрать — можно и понапрягать. Ну, еще переименовать одно в другое, ВУЗ в ПТУ, вот как медведев милицию в полицию переделал.

Полагаешь что что-то сильно изменилось? Сейчас еще одна реформа намечается, так что одним переименованием не решишь свои проблемы.

S>>Мне это не нужно, я не собираюсь давать программуху в 5м классе общеобразовательной школы.


I>А по моему ты продолжаешь утверждать, что в 5м классе дается все необходимое для программухи.

тебе кажется

S>>Тогда мне твои непонятны про 10% из 10%.


I>Мне уже поднадоело объяснять.

А ты не начинал объяснять. Ты сказал 10% из 10%, объяснений не было.

S>>Вах, разобрал по косточкам... Ну да, теперь мелочевка.

S>>З.Ы. Про 105 ячеек не напугал нисколько, реально их там работало не больше 98и, а дальше мусор гулял.

I>Наверное это специально для тебя сделали, а то у меня было 105 да еще 15 регистров памяти.

Походу 105 ты до конца не использовал... И странно что ты их считаешь "да еще", плюсуя к командным ячейкам.

I>>>"Мапить" включает в себя и интегралы и производные и много чего еще. Поверю на слово — ты все это умел в 5м классе в возрасте 14ти лет Не подскажешь, как тебе это удалось ?

S>>Аппликативные функторы твое "много чего еще" не включает?

I>А если подумать ?

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

I>У меня вопрос, кстати, а чего ты в 14 лет в пятом классе делал ?

да, подловил. Ответить "ничего" — получится как с водкой по утрам.
В 14 я ходил в 8ой.
Re[68]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.10.12 14:34
Оценка:
Здравствуйте, samius, Вы писали:

I>>Именно потому и нет смысла напрягать, следовательно надо действовать другми методами. Если на результат насрать — можно и понапрягать. Ну, еще переименовать одно в другое, ВУЗ в ПТУ, вот как медведев милицию в полицию переделал.

S>Полагаешь что что-то сильно изменилось? Сейчас еще одна реформа намечается, так что одним переименованием не решишь свои проблемы.

У себя в голове ты успешно решил эту проблему путём переименования вузов в пту

I>>Мне уже поднадоело объяснять.

S>А ты не начинал объяснять. Ты сказал 10% из 10%, объяснений не было.

Отмотай да посмотри.

I>>Наверное это специально для тебя сделали, а то у меня было 105 да еще 15 регистров памяти.

S>Походу 105 ты до конца не использовал... И странно что ты их считаешь "да еще", плюсуя к командным ячейкам.

Косвенная адресация

I>>А если подумать ?

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

Да, похоже смысла писать и пояснять нет.
Re[69]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.10.12 16:11
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


S>>Полагаешь что что-то сильно изменилось? Сейчас еще одна реформа намечается, так что одним переименованием не решишь свои проблемы.


I>У себя в голове ты успешно решил эту проблему путём переименования вузов в пту

Э не, я никакую проблему не решил, только назвал вещи своими именами. Ни качество ни количество от этого не изменилось.

S>>А ты не начинал объяснять. Ты сказал 10% из 10%, объяснений не было.


I>Отмотай да посмотри.

Блин, сначала победил здоровый скепсис. Потом одержало верх любопытство, я отмотал и любопытство слило.

Эта "значительная часть" всего процентов 10, а из них только каждый 10й может работать в ИТ.

Объяснений таки не было.

I>>>Наверное это специально для тебя сделали, а то у меня было 105 да еще 15 регистров памяти.

S>>Походу 105 ты до конца не использовал... И странно что ты их считаешь "да еще", плюсуя к командным ячейкам.

I>Косвенная адресация

которая опять-таки не может использовать ячейки ячейки команд >=100. И что, косвенная адресация как-то роднит ячейки команд с операционными регистрами?

I>>>А если подумать ?

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

I>Да, похоже смысла писать и пояснять нет.

Похоже на то. Ведь у тебя нет ничего убедительного. Разве что попробуй сослаться на опыт собеседований, медицинские книжки или знакомство с сотней ИТ-шников.
Re[70]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 25.10.12 16:33
Оценка:
Здравствуйте, samius, Вы писали:

I>>У себя в голове ты успешно решил эту проблему путём переименования вузов в пту

S>Э не, я никакую проблему не решил, только назвал вещи своими именами. Ни качество ни количество от этого не изменилось.

Ты придумал свою собственную терминологию и не решил никакой проблемы, браво !!! Прям как медведев

I>>Отмотай да посмотри.

S>Блин, сначала победил здоровый скепсис. Потом одержало верх любопытство, я отмотал и любопытство слило.
S>

S>Эта "значительная часть" всего процентов 10, а из них только каждый 10й может работать в ИТ.

S>Объяснений таки не было.

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

I>>Косвенная адресация

S>которая опять-таки не может использовать ячейки ячейки команд >=100. И что, косвенная адресация как-то роднит ячейки команд с операционными регистрами?

А где я написал что роднит ? Это ж ты решил что я так считаю. Я ведь нигде не писал что ячеек памяти программы 120 = 105 + 15 регистров. Было написано другое, из чего ты ДОДУМАЛ что я чего то приплюсовываю.

>=100 не надо использовать, потому что адрес ячейки 105 будет навроде -5 или около того. Часть адресов может использоваться, но не может отображаться на экране.

Лень вспоминать, хотя вобщем у родителей еще недавно видел этот букварик по мк61, и заглядывал в в него чисто поностальгировать
http://ru.wikipedia.org/wiki/%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8_%D0%BF%D0%BE%D0%B1%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D0%B5%D1%82%D0%B2%D0%B8
http://reocities.com/capecanaveral/hall/5525/Essai/Indirru.htm
http://ru.wikipedia.org/wiki/%D0%95%D0%B3%D0%B3%D0%BE%D0%B3%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F

I>>Да, похоже смысла писать и пояснять нет.

S>Похоже на то. Ведь у тебя нет ничего убедительного. Разве что попробуй сослаться на опыт собеседований, медицинские книжки или знакомство с сотней ИТ-шников.

Все что нужно было рассказать про map, я уже рассказал. Помнится ты во всю стебался, так что ничего удивительного.
Re[71]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 25.10.12 16:57
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>Ты придумал свою собственную терминологию и не решил никакой проблемы, браво !!! Прям как медведев

То решил, то не решил. Определись уже.

S>>Объяснений таки не было.


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

Судя по всему твои объяснения ничего не подтверждали, вот и стебался.

S>>которая опять-таки не может использовать ячейки ячейки команд >=100. И что, косвенная адресация как-то роднит ячейки команд с операционными регистрами?


I>А где я написал что роднит ? Это ж ты решил что я так считаю. Я ведь нигде не писал что ячеек памяти программы 120 = 105 + 15 регистров. Было написано другое, из чего ты ДОДУМАЛ что я чего то приплюсовываю.

Ты написал "105 ячеек да еще 15 регистров", я и подумал что ты их используешь примерно одинаково.

>>=100 не надо использовать, потому что адрес ячейки 105 будет навроде -5 или около того. Часть адресов может использоваться, но не может отображаться на экране.

Ну вот что-то было что адрес перехода берется из остатка от деления на 100.
I>Лень вспоминать, хотя вобщем у родителей еще недавно видел этот букварик по мк61, и заглядывал в в него чисто поностальгировать
I>http://ru.wikipedia.org/wiki/%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8_%D0%BF%D0%BE%D0%B1%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D0%B5%D1%82%D0%B2%D0%B8
Вот об этих циклах я и понятия не имел. Помню лишь необъяснимое поведение в хвосте ячеек команд.

S>>Похоже на то. Ведь у тебя нет ничего убедительного. Разве что попробуй сослаться на опыт собеседований, медицинские книжки или знакомство с сотней ИТ-шников.


I>Все что нужно было рассказать про map, я уже рассказал. Помнится ты во всю стебался, так что ничего удивительного.

Действительно, чему удивляться? полагаю что я нашел повод постебаться.
Re[72]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.10.12 08:09
Оценка:
Здравствуйте, samius, Вы писали:

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

S>Судя по всему твои объяснения ничего не подтверждали, вот и стебался.

Что бы чтото понять, одних умственных усилий обычно недостаточно.

I>>А где я написал что роднит ? Это ж ты решил что я так считаю. Я ведь нигде не писал что ячеек памяти программы 120 = 105 + 15 регистров. Было написано другое, из чего ты ДОДУМАЛ что я чего то приплюсовываю.

S>Ты написал "105 ячеек да еще 15 регистров", я и подумал что ты их используешь примерно одинаково.

Я в курсе, домыслы в твоем случае никогда не надо сбрасывать со счетов.

I>>Лень вспоминать, хотя вобщем у родителей еще недавно видел этот букварик по мк61, и заглядывал в в него чисто поностальгировать

I>>http://ru.wikipedia.org/wiki/%D0%93%D0%BB%D0%B0%D0%B2%D0%BD%D0%B0%D1%8F_%D0%B8_%D0%BF%D0%BE%D0%B1%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_%D0%B2%D0%B5%D1%82%D0%B2%D0%B8
S>Вот об этих циклах я и понятия не имел. Помню лишь необъяснимое поведение в хвосте ячеек команд.

Слабовато копал.
Re[73]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 26.10.12 08:22
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


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

S>>Судя по всему твои объяснения ничего не подтверждали, вот и стебался.

I>Что бы чтото понять, одних умственных усилий обычно недостаточно.

Там обошлось даже без усилий

S>>Вот об этих циклах я и понятия не имел. Помню лишь необъяснимое поведение в хвосте ячеек команд.


I>Слабовато копал.

У меня в 14 были и другие заботы
Re[74]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 26.10.12 10:51
Оценка:
Здравствуйте, samius, Вы писали:

I>>Что бы чтото понять, одних умственных усилий обычно недостаточно.

S>Там обошлось даже без усилий

Заметно.

I>>Слабовато копал.

S>У меня в 14 были и другие заботы

Алкоголь наверное ?
Re[52]: Императивное программирование
От: vdimas Россия  
Дата: 26.10.12 14:26
Оценка:
Здравствуйте, samius, Вы писали:

S>Кроме того, в базисе СП нет ни слова про "возвращать значения". Базис СП опирается на стейтменты, суть которых — изменять состояние программы. А возвращать стейтменты ничего не обязаны.


Очередное заблуждение. Основными блоками СП-программы являются процедуры и ф-ии.


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


V>>Сам кури. Что курить — я уже говорил. Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.

S>То что они могут не пересекаться — это твои личные проблемы.

Смысл вообще спорить, если ты даже не вдумываешься, что тебе пишут?


S>Наличие изменяемого состояния в тексте программы трактуется определением как императив.


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


V>>Угу, и опять, видимо, пропустил...

V>>Так не было ничего? ))
S>Экое у тебя избирательное внимание

Ну да. Это всё равно что ты настойчиво просил человека откликнуться, а когда спросили — "ну чего тебе?", в ответ — "да ничего...". Завязывай с травой, кароч.


V>>Это нормальная оценка, см. сниппеты: http://www.rsdn.ru/forum/philosophy/4932310.1
Автор: vdimas
Дата: 17.10.12

V>>В отсутствии оперирования глобальными/статическими переменными я бы дал оценку до 90% и выше для ситуаций обработки любых данных, видимых лишь из одного потока.
S>Во-первых ты забыл оперирование полями,

Ну и что у тебя не так с полями?


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


1. Очередная брехня (не натягивай свой опыт на других).

2. Опять и снова курить теорию автоматов. Конечные автоматы детерминированы, увы. Даже грязная императивная программа, использующая только глобальные переменные — обязательно детерминирована, будучи однопоточна, либо при гарантиях, когда к каждой уникальной глобальной переменной обращается лишь один поток (С — declspec(thread), C# — ThreadStaticAttribute, Threadlocal<T>). Собсно, бери даже ООП и COM на нём же. STA-объекты можно рассматривать как независимые детерминированные программы из-за тех самых гарантий.

Именно поэтому я откровенно ржу с таких заяв:

А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.

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

Помнишь тот мой спор с Синклером насчет const и pure-модификатора в некоторых императивных языках? Не читал? Могу дать ссылку.


S>Если в ФП такое оперирование сильно портит жизнь, то в ИП оно является фактически нормой. Так что, к чему ты собрался применять оценку до 90% — для меня неочевидно. Может быть для << 1% случаев, когда в программе действительно отсутствует оперирование глобальными и т.п. полями?


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


V>>Коль обсуждали все эти переупорядочивания, то идешь сейчас ты.

S>То что мы обсуждали переупорядочивания не делает оптимизаторы аргументом в пользу происхождения ФП от СП. Потому идти тебе.

Ах, ты об этом. Ну дык, я думал спор о том, что фП произошел от СП давно закончился моей полной и беззаговорочной победой.
Вот последнее сообщение на эту тему: http://www.rsdn.ru/forum/philosophy/4940409.1
Автор: vdimas
Дата: 24.10.12


Из популярных ФП языков 100% являются не-СП языками вроде бы всего два: это Хаскель и Эрланг. Это слишком мало, чтобы хоть как-то влиять на статистику и они оба слишком молоды в сравнении с ФП-парадигмой, чтобы рассуждения о происхождении ФП на их примере не были бы слишком смешными. Смирись. ФП уже де-факто произошло от СП. Всё уже случилось и ты не переиграешь произошедшего. )))


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

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

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


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


Невозможно, увы. Для такой ФП-программы нужна ФП-ось. А до тех пор, пока идет обращение к АПИ низлежащей платформы — это всё сказка про белого бычка. Любая ФП-обертка над любым хендлом/указателем — это нихрена не иммутабельный объект, даже если он выглядит в ФП-программе как иммутабельный. Т.е. ты и тут плохо понимаешь происходящее.


S>Не говоря о том, что для типичных ИП программ ни твоя ни моя редакции этого тезиса не справедливы.


Типичные ИП программы на сегодня — это ООП программы. А для них твой тезис действительно, мягко говоря из области "все вокруг идиоты". Не заносит ли тебя?


S>Обсуждать ИП, усиленное требованием отсутствия влияний состояний, мне что-то не хочется.


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

S>>>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.

V>>Никоим образом не устремляюсь. В сниппетах показал — почему.
S>И что же в них недетерминировано?

В них никакого ФП, но сплошная мутабельность. Причем, я показал вырожденные примеры. Эту мутабельность можно смело выносить за рамки методов, если сами методы снабдить модификаторами pure как в языке D или как я предлагал аналогичный модификатор clean для C++. Будет тоже самое, что в сниппетах — отсутствие скрытого влияния состояний друг на друга. Что и требовалось.
Re[39]: Императивное программирование
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.10.12 18:24
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Для Схемы не может. Целое число там не ограничено.

Омг, омг. Это, конечно же, полностью перечёркивает мой аргумент.

V>В любом случае, если компилятор может делать какие-то частичные вычисления (путь даже вычислит первые 12 значений для Схемы), это никак не служит док-вом или даже иллюстрацией к общему случаю, когда компилятор таких вещей делать не может. А мне во всех этих рассуждениях любопытен именно второй вариант, ес-но.

Ну так речь как раз о том, где кончаются способности компилятора в общем случае. Императивный компилятор в общем случае вообще не может применять никаких оптимизаций — потому что хрен его знает, зачем программист так написал. Может, там другой поток крутится, который должен иногда наблюдать ровно вот такое изменение состояния, которое кажется бессмысленным. Современные императивные языки предлагают конвенции по управлению этим процессом — скажем, считается, что в локальном коде нет неявных зависимостей, пока я не указал volatile.
Но это — всего лишь локальный код. Как только мы выходим за пределы локального кода, начинаются туман и драконы.
Да, в исследования этого тумана вкачаны огромные средства — что и позволяет вам наблюдать эффекты оптимизации в императивных языках. Решаются некоторые частные проблемы.
Однако, скажем, мне неизвестен компилятор С++, способный превратить OutFirstNFib в O(n) алгорим автоматически:
void OutFirstNFib(uint N)
{
  for(uint i=1; i<=N; i++)
    std:cout << Fib(N);
}

uint Fib(uint n)
{
   return n < 3? 1 : Fib(n-1) + Fib(n-2);
}


Для того, чтобы компилятор мог эффективно работать в общем случае, нужны явные зависимости. Речь не о частичных вычислениях, речь о построении эффективной стратегии выполнения декларативного кода. ФП — это когда функция параметризована функцией, обрабатывающей функцию. Всё, что тут может предложить ИП — спекулятивная оптимизация. В лучшем случае — хотспоттинг.
Вопросы о том, увидим ли мы прорыв в области ФП до нашей смерти, существенно зависят от банального финансирования.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[75]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 28.10.12 21:38
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, samius, Вы писали:


I>>>Что бы чтото понять, одних умственных усилий обычно недостаточно.

S>>Там обошлось даже без усилий

I>Заметно.

Я не пытался это скрывать

I>>>Слабовато копал.

S>>У меня в 14 были и другие заботы

I>Алкоголь наверное ?

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

Не устаю удивляться противоречиям, которые мирно уживаются в тебе. С одной стороны ты абслютно уверен в том что мапить школьникам рановато, а с другой — предполагаешь 14-летнему подростку было дело до недокументированного виртуального цикла от особенностей аппаратной реализации калькулятора и помешали разобраться с этим заботы об алкоголе.
А я скромно умолчу о своих догадках о том, какие заботы мешают тебе и твоим подопечным мапить.
Re[53]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 29.10.12 06:33
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Кроме того, в базисе СП нет ни слова про "возвращать значения". Базис СП опирается на стейтменты, суть которых — изменять состояние программы. А возвращать стейтменты ничего не обязаны.


V>Очередное заблуждение. Основными блоками СП-программы являются процедуры и ф-ии.

Бугога

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


V>>>Сам кури. Что курить — я уже говорил. Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.

S>>То что они могут не пересекаться — это твои личные проблемы.

V>Смысл вообще спорить, если ты даже не вдумываешься, что тебе пишут?

Смысл вдумываться, если то что ты пишешь не является аргументом в споре? Вот убеди меня сначала что программа с непересекающимися "пространствами" явных состояний перестают быть ИП, а там поглядим.

S>>Наличие изменяемого состояния в тексте программы трактуется определением как императив.


V>И что? Состояние целиком слишком огромно. Каждый раз идет модификация лишь части этого состояния. Реальную императивную программу можно разложить на слишком больше кол-во независимых автоматов.

Какая разница, на сколько именно независимых автоматов можно разложить программу? Ты когда ссылку на определения давал, читал что там написано?
V>Это не противоречит определению императива, зато противоречит твоему представлению, что императив непременное зло, так ведь?
Какое тут зло? Я всего лишь помогаю тебе разобраться в классификации. Но ты походу возомнил что я борюсь со злом....

V>Ну да. Это всё равно что ты настойчиво просил человека откликнуться, а когда спросили — "ну чего тебе?", в ответ — "да ничего...". Завязывай с травой, кароч.

Завязывай там не знаю с чем, у тебя приходы

S>>Во-первых ты забыл оперирование полями,


V>Ну и что у тебя не так с полями?

Работа с изменяемыми полями типична для ИП

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


V>1. Очередная брехня (не натягивай свой опыт на других).

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

V>2. Опять и снова курить теорию автоматов. Конечные автоматы детерминированы, увы. Даже грязная императивная программа, использующая только глобальные переменные — обязательно детерминирована, будучи однопоточна, либо при гарантиях, когда к каждой уникальной глобальной переменной обращается лишь один поток (С — declspec(thread), C# — ThreadStaticAttribute, Threadlocal<T>). Собсно, бери даже ООП и COM на нём же. STA-объекты можно рассматривать как независимые детерминированные программы из-за тех самых гарантий.

Остынь. Программа не перестает быть императивной лишь от того что она детерминирована.

V>Именно поэтому я откровенно ржу с таких заяв:

V>

V>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.

V>У тебя густая каша в голове, сорри.
V>- мутабельность не означает побочные эффекты.
С чего ты взял что я считаю иначе?
V>- наличие побочных эффектов не означает отсутствия детерминированности.
С чего ты взял что я считаю иначе?
V>- ссылочной прозрачности априори не нужна никакая иммутабельность.
С чего ты взял что я считаю иначе?

V>Помнишь тот мой спор с Синклером насчет const и pure-модификатора в некоторых императивных языках? Не читал? Могу дать ссылку.

Я счел его малосодержательным

S>>Если в ФП такое оперирование сильно портит жизнь, то в ИП оно является фактически нормой. Так что, к чему ты собрался применять оценку до 90% — для меня неочевидно. Может быть для << 1% случаев, когда в программе действительно отсутствует оперирование глобальными и т.п. полями?


V>Еще раз для тех, кто в танке. Я действительно уже 100 лет не видел императивной программы с изменяемыми глобальными переменными. В статическом виде принято хранить лишь однократно-инициализируемые, то бишь иммутабельные, данные. Я же вижу, что у тебя какое-то левое представление о том, как оно обычно бывает.

Твоя проблема в том что ты "принято" считаешь за истину в последней инстанции. Многие императивные программисты о твоем "принято" даже не догадываются. А некоторые даже счетчики для for используют глобальные. Добро пожаловать в реальный мир, Нео.

V>>>Коль обсуждали все эти переупорядочивания, то идешь сейчас ты.

S>>То что мы обсуждали переупорядочивания не делает оптимизаторы аргументом в пользу происхождения ФП от СП. Потому идти тебе.

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

V>Вот последнее сообщение на эту тему: http://www.rsdn.ru/forum/philosophy/4940409.1
Автор: vdimas
Дата: 24.10.12

Видишь ли, LISP и APL сложно считать СП-языками, учитывая то, что они произошли до появления работы Б/Я. И в ранних версиях APL даже не было управляющих конструкций... А ML — ну тут его родство с СП ограничивается тем, что ML таки слегка по-позже появился.

V>Из популярных ФП языков 100% являются не-СП языками вроде бы всего два: это Хаскель и Эрланг. Это слишком мало, чтобы хоть как-то влиять на статистику и они оба слишком молоды в сравнении с ФП-парадигмой, чтобы рассуждения о происхождении ФП на их примере не были бы слишком смешными. Смирись. ФП уже де-факто произошло от СП. Всё уже случилось и ты не переиграешь произошедшего. )))

Ну тогда назови хотя бы 100% СП языки, хоть буду знать, от чего ФП произошло )))

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


V>Невозможно, увы. Для такой ФП-программы нужна ФП-ось. А до тех пор, пока идет обращение к АПИ низлежащей платформы — это всё сказка про белого бычка. Любая ФП-обертка над любым хендлом/указателем — это нихрена не иммутабельный объект, даже если он выглядит в ФП-программе как иммутабельный. Т.е. ты и тут плохо понимаешь происходящее.

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

S>>Не говоря о том, что для типичных ИП программ ни твоя ни моя редакции этого тезиса не справедливы.


V>Типичные ИП программы на сегодня — это ООП программы. А для них твой тезис действительно, мягко говоря из области "все вокруг идиоты". Не заносит ли тебя?

У тебя какие-то фантазии относительно типичного ООП.

S>>Обсуждать ИП, усиленное требованием отсутствия влияний состояний, мне что-то не хочется.


V>Блин, курить теорию автоматов, наконец. Сразу захочется. Мне от программы нужна детерминированность и ничего более.

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

S>>>>А как только ты избавляешься от побочных эффектов и устремляешься к детерминированности, ты приближаешься к ФП-style.

V>>>Никоим образом не устремляюсь. В сниппетах показал — почему.
S>>И что же в них недетерминировано?

V>В них никакого ФП, но сплошная мутабельность. Причем, я показал вырожденные примеры. Эту мутабельность можно смело выносить за рамки методов, если сами методы снабдить модификаторами pure как в языке D или как я предлагал аналогичный модификатор clean для C++. Будет тоже самое, что в сниппетах — отсутствие скрытого влияния состояний друг на друга. Что и требовалось.

Походу ты опять не прочитал вопрос и ответил на какую-то фантазию.
Re[76]: Императивное программирование
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.10.12 08:49
Оценка:
Здравствуйте, samius, Вы писали:

I>>>>Слабовато копал.

S>>>У меня в 14 были и другие заботы

I>>Алкоголь наверное ?

S>Ты бы еще про цирроз печени написал. Я рос в порядочной семье, потому единственные заботы, связанные с алкоголем, были о том, что бы не спалиться

S>Не устаю удивляться противоречиям, которые мирно уживаются в тебе. С одной стороны ты абслютно уверен в том что мапить школьникам рановато, а с другой — предполагаешь 14-летнему подростку было дело до недокументированного виртуального цикла от особенностей аппаратной реализации калькулятора и помешали разобраться с этим заботы об алкоголе.


Ну хорошо, ты победил
Re[42]: Императивное программирование
От: AlexRK  
Дата: 29.10.12 18:36
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну, я не эксперт в оптимизирующих компиляторах, но в целом мне кажется, что экстремальные ограничения должны себя показать. Т.е. все функции — чистые; все передачи состояния — явные (то есть именно World PrintLn(World oldWorld, string line)); никакого shared.


Да, целиком согласен. Пришел к таким же выводам. Предлагаю еще память copy-on-write (концептуально, оптимизации могут частные случаи свести к указателям).
Re[54]: Императивное программирование
От: vdimas Россия  
Дата: 01.11.12 09:38
Оценка:
Здравствуйте, samius, Вы писали:

S>Вот убеди меня сначала что программа с непересекающимися "пространствами" явных состояний перестают быть ИП, а там поглядим.


Ага, зачем мне кеды, если я не курю?

Повтор для тех кто в танке:
V>>>>Состояние можно разложить на пространства. В конкретных ветках эти пространства могут не пересекаться.
S>>>То что они могут не пересекаться — это твои личные проблемы.
V>>Смысл вообще спорить, если ты даже не вдумываешься, что тебе пишут?
Re[55]: Императивное программирование
От: samius Япония http://sams-tricks.blogspot.com
Дата: 01.11.12 10:05
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, samius, Вы писали:


S>>Вот убеди меня сначала что программа с непересекающимися "пространствами" явных состояний перестают быть ИП, а там поглядим.


V>Ага, зачем мне кеды, если я не курю?


Не куришь, а других заставляешь. И кеды не тебе.

V>Повтор для тех кто в танке:

Вылазь уже из танка
Re[2]: Императивное программирование
От: dmitryalexeeff  
Дата: 07.12.12 07:51
Оценка:
Здравствуйте, DarkGray, Вы писали:


I>>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.


DG>начинай сразу с объяснения машины тьюринга — там концепций еще меньше..


DG>ps

DG>Если серьезно — то необходимо не минимальное кол-во концепций, а возможность за минимальное кол-во усилий решить реальную задачу стоящую перед пользователем. На основе лишь концепций массив, переменная, if и goto — это сделать очень и очень непросто.

Всё зависит от уровня интеллекта и прочих способностей школьника, включая мотивацию.
Умное дитё, которому грамотно и адекватно показали if/goto, такое может на них наколбасить, что вы будете очень удивлены.
Re[34]: Императивное программирование
От: vdimas Россия  
Дата: 11.12.12 00:28
Оценка:
Здравствуйте, artelk, Вы писали:

V>>Если честно, забодал подменой темы обсуждения. Речь была о упорядочивании вычислений, а не о чистоте. 99% ф-ий в современном императиве тоже чисты и что с того? Императива не существет?

A>Если бы в качестве предиката было (x>1), то во втором примере возникла бы упорядоченность вычислений?

Вот тут: http://www.rsdn.ru/forum/philosophy/4931862.1
Автор: vdimas
Дата: 17.10.12

В предпоследнем абзаце.

Отбросив слова-сорняки:

... если некие спекулятивные чистые вычисления ложных веток могут быть выполнены (как настаивают коллеги), то все-равно результат этих вычислений будет отброшен. В любом случае, всегда можно считать, что этих вычислений не было — они были совершенны фантомом в параллельном пространстве и самоиспарились. А те вычисления, что нас интересуют — будут упорядоченны именно как я сказал. То бишь даже если во времени (в ФП во времени!!!), где-то будет вычислена положительная ветка раньше, то наблюдаемого результата этих вычислений все-равно не будет до тех пор, пока не будет вычислен предикат. Т.е. даже в случае автоматического распараллеливания, результат будет отложен как аргумент той самой ф-ии в основном потоке вычислений, которая будет упорядочивать все параллельные вычисления. Упорядочивать будет, ес-но, по мере вычисления значений предикатов на ветвлении.

Re[2]: Императивное программирование
От: Ziaw Россия  
Дата: 18.12.12 05:53
Оценка:
Здравствуйте, LaptevVV, Вы писали:

I>>А что насчет циклов for?

I>> 1.Переменные
I>> 2.Массивы
I>> 3.Оператор if
I>> 4.Команды перехода (goto или jump)
I>>И все. Я могу научить человека работе с циклом for, объяснив только четыре эти концепции.
LVV>Можно без массивов, операторов if и goto...

LVV>

LVV>повторять 10 раз
LVV> что-то делаем


вово
10.times do 
  something
end


гораздо проще циклов for.
Re[3]: Императивное программирование
От: Tanker  
Дата: 10.01.13 10:59
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>вово

Z>
Z>10.times do 
Z>  something
Z>end
Z>


Z>гораздо проще циклов for.


Чем проще ? Кому проще ? Если кому то проще, то кому то и сложнее. Кому сложнее ?
Мне вот понятее так, как в естественном языке:
{ something } repeat { 10 times }
{ something } repeat { each morning } until { symptoms disappear }
{ something } repeat when { pain returns }
The animals went in two by two, hurrah, hurrah...
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.