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[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[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[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[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[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>Такое ощущение что Обама не читал мой вопрос и отвеал на что-то другое

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