Здравствуйте, thesz, Вы писали: T>>>Bottom — это и не завершимость тоже. Циклический вызов функциями друг друга в бесконечном цикле — тоже bottom. А порождения throw some_value не даёт. MC>>Изначально мы говорили о противоречии. А незавершающиеся вычисления противоречием не являются. Противоречие — это когда мы доказали что-то чего доказать не должны были.
T>Это и есть противоречие.
"Это" — это что? Незавершающиеся вычисления? Ну если ты сможешь доказать, что они не завершатся — тогда, я считаю, можно о каком-то противоречии говорить.
Кстати, в том же хаскеле явное использование undefined (ок, если хочешь, будем говорить о нем как о вычислениях, незавершимость которых доказана) как раз приводит к исключению, если вдруг потребуется его значение.
Так что я продолжаю настаивать на том, что противоречие — это исключение.
T>Так что Лисп ничему не учит.
Ты так часто это повторяешь, что я начинаю сомневаться, что ты в это веришь.
Здравствуйте, Mr.Cat, Вы писали:
T>>>>Bottom — это и не завершимость тоже. Циклический вызов функциями друг друга в бесконечном цикле — тоже bottom. А порождения throw some_value не даёт. MC>>>Изначально мы говорили о противоречии. А незавершающиеся вычисления противоречием не являются. Противоречие — это когда мы доказали что-то чего доказать не должны были.
T>>Это и есть противоречие. MC>"Это" — это что? Незавершающиеся вычисления? Ну если ты сможешь доказать, что они не завершатся — тогда, я считаю, можно о каком-то противоречии говорить.
Так охота послать тебя изучать теорию.
Ещё раз: я могу использовать незавершающиеся вычисления в качестве адекватной замены противоречию. Как из A&!A можно доказать что угодно, так и x = x может быть подставлено куда угодно для формирования доказательства чего угодно.
MC>Кстати, в том же хаскеле явное использование undefined (ок, если хочешь, будем говорить о нем как о вычислениях, незавершимость которых доказана) как раз приводит к исключению, если вдруг потребуется его значение.
Ух ты! Что это должно доказывать?
А если я определю undefined = undefined, то что будет?
MC>Так что я продолжаю настаивать на том, что противоречие — это исключение.
Противоречие — это то, что позволяет получить противоречивые модели.
T>>Так что Лисп ничему не учит. MC>Ты так часто это повторяешь, что я начинаю сомневаться, что ты в это веришь.
Ещё раз: Лисп ничему не учит.
К сожалению, повторение — практически единственный универсальный способ обучения.
Я это повторяю не потому, что верю, а для того, чтобы у тебя в мозгах осталась хотя бы такая простая мысль.
Я её пытаюсь подтвердить аргументами, но это на тебя оказывает очень небольшое воздействие. Думаю, что простое повторение "Лисп ничему не учит" будет проще и выгодней.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
AVK>>А я к тому, что это сугубо твое субъективное видение.
T>Это моё объективное опровержение чьего-то ещё (выше по ветке) сугубо субъективного видения.
Для объективности необходимы аргументы, а не софистика.
T>То, что ты называешь "умением программировать" (если принять в расчёт твои ответы "да" выше, а не только твои высказывания тут и выше), называется умением комбинировать известные решения.
Никак нет.
T>Ты не прав потому, что в твоих рассуждениях есть противоречие. С одной стороны ты говоришь, что умение программировать не зависит от парадигмы
Да.
T>, а с другой стороны признаешь за не умеющими пользоваться более, чем одной парадигмой (более, чем одним средством внутри парадигмы) умение программировать.
Да. Противоречия не вижу.
T>Если умение программировать не зависит от парадигмы, то умеющий программировать перескакивал бы с одной парадигмы на другую без проблем
С какой стати?
T>, начиная программировать в очередной через пару недель изучения.
Ну, вот Влад тебе расскажет, сколько нужно человеку для освоения ФП на примере Немерле. Лично я не вижу никаких препятствий для опытного программиста в освоении концепций ФП за единицы недель.
T>Чего мы не наблюдаем практически ни у кого.
Не наблюдаем мы этого в основном из-за отсутствия необходимости в этом. Вобщем, опять логическая подтасовка. Если мы не наблюдаем на улице массу взрослых, играющих в классики, это не означает что они не в состоянии этого делать.
T>Так что, либо умение программировать зависит-таки от парадигмы (от набора известных инструментов), либо практически никто не умеет программировать.
Все та же ложная альтернатива.
T>>>А так, как есть — увы. Ты неправ. AVK>> Увы, но не прав ты.
T>Не рекомендую.
Чего?
... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
Здравствуйте, thesz, Вы писали:
T>Я её пытаюсь подтвердить аргументами, но это на тебя оказывает очень небольшое воздействие. Думаю, что простое повторение "Лисп ничему не учит" будет проще и выгодней.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, thesz, Вы писали:
AVK>>>А я к тому, что это сугубо твое субъективное видение.
T>>Это моё объективное опровержение чьего-то ещё (выше по ветке) сугубо субъективного видения. AVK>Для объективности необходимы аргументы, а не софистика.
Для объективности нужны проверяемые (фальсифицируемые) предположения.
Все мои предположения в этой ветке являются фальсифицируемыми.
Следовательно, я объективен.
T>>То, что ты называешь "умением программировать" (если принять в расчёт твои ответы "да" выше, а не только твои высказывания тут и выше), называется умением комбинировать известные решения. AVK>Никак нет. T>>Ты не прав потому, что в твоих рассуждениях есть противоречие. С одной стороны ты говоришь, что умение программировать не зависит от парадигмы AVK>Да. T>>, а с другой стороны признаешь за не умеющими пользоваться более, чем одной парадигмой (более, чем одним средством внутри парадигмы) умение программировать. AVK>Да. Противоречия не вижу.
Что ж.
Oppsotion rests, как говорят нашу зарубежные друзья.
T>>Если умение программировать не зависит от парадигмы, то умеющий программировать перескакивал бы с одной парадигмы на другую без проблем AVK>С какой стати? T>>, начиная программировать в очередной через пару недель изучения. AVK>Ну, вот Влад тебе расскажет, сколько нужно человеку для освоения ФП на примере Немерле. Лично я не вижу никаких препятствий для опытного программиста в освоении концепций ФП за единицы недель.
Влад до сих пор не может понять, зачем нужны ленивые вычисления. Так что до понимания ФП ему очень далеко.
Всё, чему он научился — это использованию ФВП и сравнения с образцом в императивном программировании.
T>>Чего мы не наблюдаем практически ни у кого. AVK>Не наблюдаем мы этого в основном из-за отсутствия необходимости в этом. Вобщем, опять логическая подтасовка. Если мы не наблюдаем на улице массу взрослых, играющих в классики, это не означает что они не в состоянии этого делать.
Вот здесь — подтасовка. Сведение к абсурду.
Игра в классики не может быть сравнена с программированием.
Более того, необходимость в переходах между парадигмами есть — если, конечно, человек стремится сделать себя лучшим программистом.
T>>Так что, либо умение программировать зависит-таки от парадигмы (от набора известных инструментов), либо практически никто не умеет программировать. AVK>Все та же ложная альтернатива.
Опровержение ложной альтернативы очень просто: достаточно расширить выбор.
Ты этого до сих пор не сделал, значит, ложной альтернативы здесь нет.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, thesz, Вы писали:
E>>Так что умение написать сбалансированное дерево самостоятельно это либо слишком мало (если умеешь, потому, что прочитал как это сделать), либо слишком много (если предполагается, что ты можешь все структуры данных с нуля родить)
T>ЕЩЁ НЕ РЕШЁННЫЕ задачи можно решать в комбинационном стиле, используя известные приёмы. Комбинируя структуры данных из STL, например.
Можно и так, но не всегда. В любом случсе программист -- это инженер, который должен понимать какие решения и почему он принял, на какие компромисы и ограничения он пошёл и почему и зачем именно на такие.
Короче должен стремится решить задачу так просто, как только возможно, не не проще.
Вот для оценки этой границы и нужно быть хорошим инженером. А второе, что нужно, это восприимчиворсть к новым технологиям и инструментам, способность учиться, правда помноженная на здоровый скептицизм и консерватизм...
T>Особенно с учётом оценки "приемлемо".
Ну вот, IMHO, с понимания, что бывают решения, вроде бы корректные, но непримлимые и начинается воспитание инженера...
T>>>Человек отлично знает, как программировать на C#. Способен справится с любой задачей (как он считает). На Хаскеле что-либо делать стремается. E>>IMHO, это вообще к умению программировать отношения не имеет никакого T>Почему не имеет отношения? Ты сам себе противоречишь.
Это так только кажется, потому, что логика отстой, так как мысль изречнная есть ложь
А вообще-то, выбор языка обычно либо вообще невозможен, либо не очень важен.
Тем более выбор маргинального языка, вместо апробированного общепринятого и надёжного подхода...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, thesz, Вы писали:
T>Это означает, что "умение программировать" сводится к применению набора приёмов.
Нет. Это умения кодера, а не программиста.
T>Если оно доказуемо не распространяется не то, что на другие парадигмы, а даже просто на другие алгоритмы.
Эту фразу я так и не распарсил. Увы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, thesz, Вы писали:
T>Ты не прав потому, что в твоих рассуждениях есть противоречие. С одной стороны ты говоришь, что умение программировать не зависит от парадигмы, а с другой стороны признаешь за не умеющими пользоваться более, чем одной парадигмой (более, чем одним средством внутри парадигмы) умение программировать.
T>Если умение программировать не зависит от парадигмы, то умеющий программировать перескакивал бы с одной парадигмы на другую без проблем, начиная программировать в очередной через пару недель изучения. Независимые сущности не оказывают влияния друг на друга.
T>Чего мы не наблюдаем практически ни у кого.
Просто для достижения конечногорезультата одного умения программировать мало. Нужно ещё и каким-то инструментарием овладеть. Так что каждый реальный программист зависит как минимум от двух обстоятельств.
1) Насколько он хорош как инженер-программист (то самое "умение программировать")
2) Насколько он владеет используемым инструментарием.
При этом первое качество намного реже встречается и тяжелее воспитывается, чем второе.
И при этом примеры того, как люди, обладающие первым качеством, при смене инструментария, всё равно остаются хорошими программистами, и есть ещё больше примеров того, как люди не обладающие первым качеством при многочисленных сменах инструментария хорошими программистами не становятся...
А что касается того, чему там учат лисп с хаскелем, так я тебе такой аналог твоего рассуждения приведу: "Понимание того, как надо заниматься сексом зависит от пола участника, так как иначе всем бы было всё равно кого трахать". В этом "рассуждении" есть логическая ошибка. Точно такая же есть и в твоих "рассуждениях"...
T>Или по другому: либо умение программировать условно (содержит условия, в которых кто-то умеет программировать), либо безусловно и не существует в природе.
А существует ли в природе "умение управлять заводом", или "умение быть бизнесменом" или что-то ещё в таком духе?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, thesz, Вы писали: T>Так охота послать тебя изучать теорию.
Что мешает? Годным ссылкам на матчасть буду только рад.
T>Ещё раз: я могу использовать незавершающиеся вычисления в качестве адекватной замены противоречию. Как из A&!A можно доказать что угодно, так и x = x может быть подставлено куда угодно для формирования доказательства чего угодно.
Ок, эта связь между противоречиями и незаваршающимися вычислениями понятна. Но ведь не все выражения, приводящие к незавершающимся вычислениям имеют произвольный тип, ака доказывают что угодно.
T>Противоречие — это то, что позволяет получить противоречивые модели.
Теперь понятно. Я говорил о последствиях противоречий, которыми являются исключения и, пожалуй да, незавершающиеся вычисления. Ты говорил о собственно противоречиях, на основе которых можно получать (бесполезные — ибо, например, не завершаются) доказательства чего угодно. И да, если подходить с твоего конца, вполне очевидно, что лиспы сами по себе не предоставляют языка для записи высказываний ака типов, поэтому программы на лиспах сами по себе какбы ничего и не доказывают.
T>Я её пытаюсь подтвердить аргументами, но это на тебя оказывает очень небольшое воздействие. Думаю, что простое повторение "Лисп ничему не учит" будет проще и выгодней.
Пока ты приводишь аргументы, с тобой интересно разговаривать. Шаблонными мантрами и копипастой тут вряд ли кого-то заинтересуешь.
Здравствуйте, B7_Ruslan, Вы писали:
B_R>О себе: учусь на 4м курсе. Уверенно пользуюсь С++ для повседневных нужд(курсовики себе и на заказ). B_R>Постоянно работать не пробовал и не могу себе позволить во время учебы — прогулы жестко караются.
Если речь идет о трудоустройстве и в деньгах в ближней перспективе, то перспективность того или иного языка программирования должна определяться форумом "О работе" -> "Предложения от работодателей", а не форумом "Философия программирования", т.к. именно рынок труда (желательно именно твоего места проживания) подскажет тебе язык программирования.
Если же вести речь о более дальних перспективах, то здесь быть оригинальным сложно: нужно работать, совершенствоваться, стремиться к постоянному развитию, вещи, в общем-то прописные, но не всегда легко выполнимые.
Есть такие подкасты для разработчиков, Software Engineering Radio (http://se-radio.net), в них поднимаются самые различные темы, начиная от проблем многопоточности, вопросах архитектуры, шаблонов проектирования, заканчивая интервью со знаменитыми людьми (Хейлберг, Мейер, Буч и др.). Так вот, почти в каждом интервью задают такой последний вопрос: "Какими качествами должен обладать идеальный программист?", мне очень понравились ответы Дейва Томаса (http://se-radio.net/podcast/2008-02/episode-86-interview-dave-thomas)
Okay so to wrap this up, a question that I have asked several other people as a kind of final question. What do you think it takes to be a good software engineer or developer, programmer kind of person? What is it that makes a good programmer?
DT: Oh, boy if I knew that it would be -- clearly the ability to deal with abstraction.
Modeling, conceptual modeling --
DT: Modeling and conceptual modeling, clearly the ability to communicate and I think you have to have a passion for problem solving and I think you have to care about the code you write in the sense that it's just not enough to get it done. You've got to view it, you have to view it as an expression. I wouldn't go so far as to call it literature I mean the literate program that you really are not happy.
The sense of beauty --
DT: You want to refine it till the point you want to polish it to the point, to the point that this is good. That this is something I am proud of, I've done it and typically reduce the blow to get it into a small compact form.
Fan mail --
DT: Well, I don't know about fan mail may but the darts can come but I think being here with Fred Brooks and other people, you just appreciate that software is hard and making sure that -- I think mentoring and apprenticing. I mean the whole, that's craftsmanship that the whole -- that's really important. I mean if you really want to be good find somebody who is really good and try and work with them, right. Find someone who will criticize your work. So you have to get better and work with the best, right so and if you are the best in your organization, you are probably hurting yourself, right. Being three or four years or five years the best, you should be looking for someone else to work with --
No challenge anymore.
DT: That's right; you will actually start believing that you are the best.
Здравствуйте, RemoteCoder, Вы писали:
>>Какой язык начать изучать на перспективу?
RC>Судя по кризису и экономическим успехам Китая... — китайский
В ж<тут_подразумевалось_неприличное_слово/> китайский, Я йероглифами писать программы не согласен . Индусы, кстати, тоже не плохо развиваются, а у них английский вроде..
Здравствуйте, PathFinder_II, Вы писали:
PF_>В ж<тут_подразумевалось_неприличное_слово/> китайский, Я йероглифами писать программы не согласен . Индусы, кстати, тоже не плохо развиваются, а у них английский вроде..
Не дай Бог тебе читать такой английский.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, B7_Ruslan, Вы писали:
B_R>О себе: учусь на 4м курсе. Уверенно пользуюсь С++ для повседневных нужд(курсовики себе и на заказ). B_R>Постоянно работать не пробовал и не могу себе позволить во время учебы — прогулы жестко караются.
Здравствуйте, B7_Ruslan, Вы писали:
B_R>О себе: учусь на 4м курсе. Уверенно пользуюсь С++ для повседневных нужд(курсовики себе и на заказ). B_R>Постоянно работать не пробовал и не могу себе позволить во время учебы — прогулы жестко караются.
C# + английский (советующим учить китайский: определенный смысл есть, но я своими глазами вижу (я сейчас в азии), как азиаты разных наций между собой вынуждены общаться на английском(!), дефакто это язык глобализации и таковым останется в обозримой перспективе.
а вообще хинт такой: можно выучить мэйнстримовый язык и стать специалистом в мэйнстриме -- работы будет много, найти ее будет легко, но з/п будет не слишком высокой; можно освоить узкую и специальную область (например, написание драйверов), освоить будет сложнее, предложений по работе немного, но будучи хорошим специалистом, з/п будете иметь заметно выше.
Здравствуйте, vitasr, Вы писали:
V>а вообще хинт такой: можно выучить мэйнстримовый язык и стать специалистом в мэйнстриме -- работы будет много, найти ее будет легко, но з/п будет не слишком высокой; можно освоить узкую и специальную область (например, написание драйверов), освоить будет сложнее, предложений по работе немного, но будучи хорошим специалистом, з/п будете иметь заметно выше.
А еще можно освоить мейнстрим и быть на две головы выше основной массы, тогда з/п будет еще выше.
... << RSDN@Home 1.2.0 alpha 4 rev. 1428 on Windows 7 6.1.7600.0>>
Что такое мейнстрим в России и за границей(не США)?
В России примерно соображаю — сайты делать(в одиночку — PHP, если есть деньги — на конструкторах от МС). Но в этом я пока — ноль, совсем ноль. Сколько может уйти времени на освоение сайтостроя(хотя бы в одном режиме)?
Тем временем делаю бакалаврскую с использованем Qt и MSVC без интеграции.
Пока стараюсь использовать стратегию, при которой весь предыдущий опыт(хоть и не большой) остается нужным.
Т.е. читаю Саттера, использую популярные либы.
Стоит ли заняться созданием драйверов(автоматически подразумевается, что нужно сперва сделать свой девайс)? Сколько на это может уйти времени, при условии что в текущем семестре у нас будут лабораторные работы по программированию мк, в следующем семестре мне надо будет разработать устройство на базе мк?
Увы, но не прав ты.
. Индусы, кстати, тоже не плохо развиваются, а у них английский вроде..
