Народ, на форуме буквально неделю назад жаркая дискусия была по поводу программирования с++ vs ???. Были и такие сообщения, что на с++ пишут процентов 5-10 кода, остальное на каких-то других языках, о которых я например и не слышал. Теперь ничего не понимаю, выходит чтоб быстро и эффективно программить надо забыть про с++, и учить всякие скриптовые языки, учить ocalm и т.д.? Народ поделитесь еще и тем, какие современные технологии помогают быстро писать обычный, не специализированный софт...
28.12.05 13:53: Перенесено из 'Философия программирования'
Здравствуйте, stragner, Вы писали:
S>Народ, на форуме буквально неделю назад жаркая дискусия была по поводу программирования с++ vs ???. Были и такие сообщения, что на с++ пишут процентов 5-10 кода, остальное на каких-то других языках, о которых я например и не слышал. Теперь ничего не понимаю, выходит чтоб быстро и эффективно программить надо забыть про с++, и учить всякие скриптовые языки, учить ocalm и т.д.? Народ поделитесь еще и тем, какие современные технологии помогают быстро писать обычный, не специализированный софт...
Ну вот, опять 398 итерация...
Помогают не технологии, а умение в них разбираться и выбирать.
А пока этого не наблюдается, остается лишь полагаться на мнение большинства.
Здравствуйте, reductor, Вы писали: R>Помогают не технологии, а умение в них разбираться и выбирать. R>А пока этого не наблюдается, остается лишь полагаться на мнение большинства. R>Больше сказать нечего. R>Умеющий уши, да услышит.
В том то и дело, что надо в них разбираться. Но для этого надо что выбрать, и что делать новичкам?
Здравствуйте, stragner, Вы писали:
S>Здравствуйте, reductor, Вы писали: R>>Помогают не технологии, а умение в них разбираться и выбирать. R>>А пока этого не наблюдается, остается лишь полагаться на мнение большинства. R>>Больше сказать нечего. R>>Умеющий уши, да услышит.
S>В том то и дело, что надо в них разбираться. Но для этого надо что выбрать, и что делать новичкам?
Вы не о том спрашиваете и не там.
Спросите себя — зачем вы программируете?
Чтобы просто получать N долларов в час за работу и программирование для вас просто способ зарабатывания на хлеб с маслом — тогда совершенно неважно что выбирать. Платить вам будут всегда за время здесь или там — и технологии не имеют никого значения.
А если вам это интересно и вы хотите развиваться, учиться и вообще расти как профессионал потому что вам это нравится — тогда учить следует все подряд. А иначе — ничего не выйдет. Читать дискуссии, документацию, книжки и самостоятельно, вдумчиво сравнивать одно с другим и задавать _себе_ вопрос кто прав, а кто — нет.
Да, это требует много времени, сил, упорства и денег. Но если вам интересно, это все ерунда и взамен вы для себя получите гораздо больше. Даже если придется убедиться, что ничего менять не нужно.
Ладно...
Краткий список языков, которые лично я отношу к обязательной программе (знания) — ML(SML/O'Caml), Scheme, Common Lisp, Haskell, Prolog, Smalltallk и Forth. Ну еще, видимо, не помешает APL/J/K.
Не так уж кстати и много. Зато после них входишь во вкус и начинашь щелкать языки как орехи.
И упаси боже пытаться выбрать среди них тот, что "лучше".
Здравствуйте, reductor, Вы писали:
R>Вы не о том спрашиваете и не там. R>Спросите себя — зачем вы программируете? R>Чтобы просто получать N долларов в час за работу и программирование для вас просто способ зарабатывания на хлеб с маслом — тогда совершенно неважно что выбирать. Платить вам будут всегда за время здесь или там — и технологии не имеют никого значения.
R>А если вам это интересно и вы хотите развиваться, учиться и вообще расти как профессионал потому что вам это нравится — тогда учить следует все подряд. А иначе — ничего не выйдет. Читать дискуссии, документацию, книжки и самостоятельно, вдумчиво сравнивать одно с другим и задавать _себе_ вопрос кто прав, а кто — нет. R>Да, это требует много времени, сил, упорства и денег. Но если вам интересно, это все ерунда и взамен вы для себя получите гораздо больше. Даже если придется убедиться, что ничего менять не нужно.
Простите, что не по теме. Можно вопрос личного характера? Вы женаты? Дети?
Здравствуйте, reductor, Вы писали:
R>>>Помогают не технологии, а умение в них разбираться и выбирать.
<...skipped...>
S>>В том то и дело, что надо в них разбираться. Но для этого надо что выбрать, и что делать новичкам?
<...skipped...>
R>Ладно... R>Краткий список языков, которые лично я отношу к обязательной программе (знания) — ML(SML/O'Caml), Scheme, Common Lisp, Haskell, Prolog, Smalltallk и Forth. Ну еще, видимо, не помешает APL/J/K. R>Не так уж кстати и много. Зато после них входишь во вкус и начинашь щелкать языки как орехи.
Жаль, что здесь неявно подразумевается, что "знания" == "умения". Это далеко не всегда так.
На заре своей трудовой деятельности я наблюдал несколько раз, как хорошо эрудированные, умные и способные программисты заваливали проекты. А рядом с ними работали гораздо менее "продвинутые" команды, которые успешно сдавали свои проекты, хоть и использовали более примитивные и корявые решения.
Происходило это потому, что нарушалось простое правило: "Лучшее враг хорошего". В погоне за красотой решения или какими-то другими эфимерными целями легко забыть, что в производстве ПО главное -- это работающий продукт, а еще лучше, если он был сделан во время. И здесь оказывается, что тупое решение на C, сделанное методом Copy&Paste, оказывается успешнее, чем маленькое, элегантное и красивое решение на какой-нибудь замечательной технологии, но сделанное позже, или вообще не доделанное.
Продолжая высказывание reductor-а, я бы сказал, что в нашей профессии вообще нужно держать мозги открытыми для новых технологий и очень желательно иметь способности к быстрому обучению/переобучению. Поэтому, чем больше ты будешь знать и чем легче ты будешь осваивать новый материал, тем проще и лучше может оказаться для тебя лично. Но не факт, что это положительно отзовется на твоих проектах. Поскольку для успешности проектов, все же, важнее не знания, а умения.
R>И упаси боже пытаться выбрать среди них тот, что "лучше".
Хм... Сложно спорить, но я пропробую сделать ремарку. Имхо, в большом, долгоиграющем проекте, где очень большая вероятность ротации членов коллектива по ходу разработки, с административной точки зрения, лучше минимизировать количество языков. Вот тогда приходится делать выбор. Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
E>Жаль, что здесь неявно подразумевается, что "знания" == "умения". Это далеко не всегда так.
E>На заре своей трудовой деятельности я наблюдал несколько раз, как хорошо эрудированные, умные и способные программисты заваливали проекты. А рядом с ними работали гораздо менее "продвинутые" команды, которые успешно сдавали свои проекты, хоть и использовали более примитивные и корявые решения.
Я в трефу и покойничек в трефу, я в бубну и покойничек в бубну... (с)
E>Хм... Сложно спорить, но я пропробую сделать ремарку. Имхо, в большом, долгоиграющем проекте, где очень большая вероятность ротации членов коллектива по ходу разработки, с административной точки зрения, лучше минимизировать количество языков. Вот тогда приходится делать выбор. Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
И это вы утверждаете не зная ни тикля ни перла ни питона, что характерно.
Исключительно административно.
Кстати, про административную точку зрения. Какими по размеру проектами вы управляли, сколько там было человек, языков и в течение какого срока?
Здравствуйте, stragner, Вы писали:
S>В том то и дело, что надо в них разбираться. Но для этого надо что выбрать, и что делать новичкам?
Ну, вот выучи один может два функциональных языка. Изучи дотнет с C# или Яву. Будет тебе хороший задел для размышлений. Можно еще изучить Руби или Питон.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Ну, вот выучи один может два функциональных языка. Изучи дотнет с C# или Яву. Будет тебе хороший задел для размышлений. Можно еще изучить Руби или Питон.
ИМХО, для достижения просветления достаточно "всего лишь" разобраться в исходниках GCC Очень поучительное чтиво.
Здравствуйте, reductor, Вы писали:
E>>Жаль, что здесь неявно подразумевается, что "знания" == "умения". Это далеко не всегда так.
E>>На заре своей трудовой деятельности я наблюдал несколько раз, как хорошо эрудированные, умные и способные программисты заваливали проекты. А рядом с ними работали гораздо менее "продвинутые" команды, которые успешно сдавали свои проекты, хоть и использовали более примитивные и корявые решения.
R>Я в трефу и покойничек в трефу, я в бубну и покойничек в бубну... (с)
Если чесно, то я не понял, каким образом данная цитата соотносится с моей фразой.
E>>Хм... Сложно спорить, но я пропробую сделать ремарку. Имхо, в большом, долгоиграющем проекте, где очень большая вероятность ротации членов коллектива по ходу разработки, с административной точки зрения, лучше минимизировать количество языков. Вот тогда приходится делать выбор. Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
R>И это вы утверждаете не зная ни тикля ни перла ни питона, что характерно.
А почему вы думаете, что если я их не знаю, то я вообще не имею о них представления?
Год назад я занимался выбором скриптового языка для своего проекта и перебрал массу языков, в число которых входили и Tcl/Tk, и Perl, и Python, и c-smile, и Groovy, и Lua, и Ruby, и Limbo, и еще пара-тройка языков, названия которых я уже забыл. Первым фактором для оценки для меня являлось число платформ на которых существовали реализации данных языков. Поэтому в финал вышли Tcl/Tk, Perl, Python и Ruby. Выбор я делал из них уже по свойствам самих языков, поэтому Tcl/Tk практически сразу вылетел, а сравнивались Perl, Python и Ruby. Ruby выиграл.
R>Исключительно административно.
Именно так.
R>Кстати, про административную точку зрения. Какими по размеру проектами вы управляли, сколько там было человек, языков и в течение какого срока?
Администратором и ПМ я никогда не был. Но вот практически всегда приходилось заниматься выбором инструментов и технологий, либо высказывать свое мнение по поводу этого выбора. Что касается проектов, то было несколько "долгоиграющих". В одном я участвовал с 1994 по 2000, затем часть этого проекта была реинкарнированна в другой ипостаси в 2002 и до сих про развивается. Еще в нескольких я участвую сейчас, они разрабатываются с 2001 года. Проекты разного объема, от 40-60 тысяч строк до 150-250 тысяч строк. Команды, в основном, небольшие, 1-2 человека, но несколько раз было по 4-5 человек, хотя и тогда было бы правильнее говорить о 3-4 относительно независимых частях объемом в 60-70 тысяч строк, разработкой которых занимались 1-2 человека. Практически все проекты разрабатывались на одном языке (либо C++, либо Java), хотя бывали и связки C++ и Java. Сейчас я пишу на системы на C++, которые администрируются и настраиваются с помощью Ruby. Так же кое-где Ruby используется для кодогенерации. Это все о проектах, в которых участвовал лично я. За некоторыми проектами мне довелось наблюдать со стороны.
Свои заключения о необходимости минимизации количества инструментов, используемых в проекте, я делаю на основании опыта, который был получен при переформировании проектных команд, при замене выбывающих из разработки по объективным причинам коллег, при обучении новых сотрудников. А также наблюдением за тем, как происходит изучения и овладение новыми библиотеками/фреймворками даже в рамках одного языка программирования.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
R>>Я в трефу и покойничек в трефу, я в бубну и покойничек в бубну... (с)
E>Если чесно, то я не понял, каким образом данная цитата соотносится с моей фразой. :???:
Ничего страшного.
R>>И это вы утверждаете не зная ни тикля ни перла ни питона, что характерно.
E>А почему вы думаете, что если я их не знаю, то я вообще не имею о них представления? E>Год назад я занимался выбором скриптового языка для своего проекта и перебрал массу языков, в число которых входили и Tcl/Tk, и Perl, и Python, и c-smile, и Groovy, и Lua, и Ruby, и Limbo, и еще пара-тройка языков, названия которых я уже забыл. Первым фактором для оценки для меня являлось число платформ на которых существовали реализации данных языков. Поэтому в финал вышли Tcl/Tk, Perl, Python и Ruby. Выбор я делал из них уже по свойствам самих языков, поэтому Tcl/Tk практически сразу вылетел, а сравнивались Perl, Python и Ruby. Ruby выиграл.
То есть вы их знаете?
А не расскажете почему тикль вылетел. Кстати язык называется Tcl, а Tk — это библиотека для построения UI.
Но тем не менее, может расскажете какое преимущество имеет питон перед перлом, перл перед тиклем, а руби перед всеми ними. Очень интересно.
R>>Кстати, про административную точку зрения. Какими по размеру проектами вы управляли, сколько там было человек, языков и в течение какого срока?
E>Администратором и ПМ я никогда не был.
Уже хорошо
E>Свои заключения о необходимости минимизации количества инструментов, используемых в проекте, я делаю на основании опыта, который был получен при переформировании проектных команд, при замене выбывающих из разработки по объективным причинам коллег, при обучении новых сотрудников. А также наблюдением за тем, как происходит изучения и овладение новыми библиотеками/фреймворками даже в рамках одного языка программирования.
Здравствуйте, reductor, Вы писали:
E>>Если чесно, то я не понял, каким образом данная цитата соотносится с моей фразой.
R>Ничего страшного.
<offtopic>
Попробуйте изменить манеру общения.
</offtopic>
R>>>И это вы утверждаете не зная ни тикля ни перла ни питона, что характерно.
E>>А почему вы думаете, что если я их не знаю, то я вообще не имею о них представления? E>>Год назад я занимался выбором скриптового языка для своего проекта и перебрал массу языков, в число которых входили и Tcl/Tk, и Perl, и Python, и c-smile, и Groovy, и Lua, и Ruby, и Limbo, и еще пара-тройка языков, названия которых я уже забыл. Первым фактором для оценки для меня являлось число платформ на которых существовали реализации данных языков. Поэтому в финал вышли Tcl/Tk, Perl, Python и Ruby. Выбор я делал из них уже по свойствам самих языков, поэтому Tcl/Tk практически сразу вылетел, а сравнивались Perl, Python и Ruby. Ruby выиграл.
R>То есть вы их знаете?
Нет, не знаю, т.к. не программировал на них серьезно. В моем представлении "знать" -- это значит быть очень осведомленным о языке и иметь большой опыт программирования на этом языке. Поэтому я даже про C++ стараюсь не говорить, что я его знаю. Я на нем много программирую. По-моему, из участников форумов RSDN, знают C++ такие уважемые мной коллеги, как Павел Кузнецов, Андрей Тарасевич, Кодт, MaximE. Рядом с ними мои познания в C++ вообще нулевые.
Подобным образом я могу сказать и о Ruby.
Но это совершенно не мешает мне представлять в общих чертах, что такое Tcl/Tk и что такое Python.
R>А не расскажете почему тикль вылетел. Кстати язык называется Tcl, а Tk — это библиотека для построения UI.
Я знаю. Тем не менее, расматривал я связку именно Tcl/Tk.
А не понравился он мне своей, как бы это сказать, направленностью, проистекающей из названия (Tool Command Language, если не ошибаюсь). И вот таким кодом, в частности:
proc power {base p} {
set result 1
while {$p > 0} {
set result [expr $result * $base]
set p [expr $p - 1]
}
return $result
}
Ну не нравиться мне вместо result *= base писать set result [expr $result * $base].
R>Но тем не менее, может расскажете какое преимущество имеет питон перед перлом, перл перед тиклем, а руби перед всеми ними. Очень интересно.
Преимуществ вообще? Тогда это не ко мне. Мне не интересны языки сами по себе.
А вот преимущества для моей конкретной задачи я описывал
.
R>>>Кстати, про административную точку зрения. Какими по размеру проектами вы управляли, сколько там было человек, языков и в течение какого срока?
R>То есть вы — администратор-теоретик?
Нет, я программист-практик. Причем, программист-камиказде, который умудряется встревать в безнадежные проекты. И очень часто приходится выполнять сразу множество ролей: и аналитика, и архитектора, и тестировщика, и документатора. А иногда и внедрением, и обслуживанием приходилось заниматься.
<offtopic>
В отличии от вашего анонимного участия в RSDN, я здесь под своим реальным именем. Никому не составляет труда зайти на мою страничку, узнать кто я, чем занимаюсь и увидеть, как это у меня получается. Попытки подколоть меня или выставить невеждой/неумехой/тупым увальнем заранее обречены на неудачу, т.к. если бы меня это волновало, то я бы не стал здесь участвовать вообще. Так что мне совершенно фиолетово, если сотни людей составят обо мне подобное впечатление. Более важно, что благодоря участию в RSDN я приобрел нескольких уважаемых мной знакомых, которые хорошо относятся и ко мне, и к результатам моих разработок.
</offtopic>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Но это совершенно не мешает мне представлять в общих чертах, что такое Tcl/Tk и что такое Python.
E>А не понравился он мне своей, как бы это сказать, направленностью, проистекающей из названия (Tool Command Language, если не ошибаюсь). И вот таким кодом, в частности: E>Ну не нравиться мне вместо result *= base писать set result [expr $result * $base].
Какая направленность, кто на ком стоял — ничего не понятно.
R>>Но тем не менее, может расскажете какое преимущество имеет питон перед перлом, перл перед тиклем, а руби перед всеми ними. Очень интересно.
E>Преимуществ вообще? Тогда это не ко мне. Мне не интересны языки сами по себе.
Вы сказали, что в случае трех языков — Tcl, Perl и Python — выбор должен пасть на питон.
Я спрашиваю — почему.
Разумеется, претензии к синтаксису не являются ответом на вопрос.
E>А вот преимущества для моей конкретной задачи я описывал
А зачем вы там врете по ссылке? Closures есть везде (и в тикле и в перле и даже в питоне) и передавать их можно куда угодно, а лисп — не менее императивный язык, чем руби и синтаксиса у лиспа нет вообще никакого. Ни птичьего ни земноводного.
R>>То есть вы — администратор-теоретик?
E>Нет, я программист-практик. Причем, программист-камиказде, который умудряется встревать в безнадежные проекты. И очень часто приходится выполнять сразу множество ролей: и аналитика, и архитектора, и тестировщика, и документатора. А иногда и внедрением, и обслуживанием приходилось заниматься.
Замечательно. Опыта управления нет. Опыта участия в действительно больших проектах нет. Советов по теме — целый воз.
Здравствуйте, reductor, Вы писали:
R>То есть вы не в курсе, что тикль — язык расширяемый. Что это метаязык и что вы вольны писать в нем так, как вам того хочется? R>http://www.invece.org/tclwise/extending_tcl_in_tcl.html
Пожалуйста, изобразите на TCL пример описания проекта, который я показывал здесь
на Ruby и XML.
R>Вы сказали, что в случае трех языков — Tcl, Perl и Python — выбор должен пасть на питон. R>Я спрашиваю — почему.
Я ничего не утверждал. Прочитайте внимательно:
Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
R>Разумеется, претензии к синтаксису не являются ответом на вопрос.
А для меня являются. Может быть с научных позиций это совершенно бессмыслено, но я говорю про практику, про то, что мне этот язык придется использовать. И если мне нужно писать set вместо =, и префиксовать каждую переменную $, то я лучше поищу язык, где этого делать не нужно.
E>>А вот преимущества для моей конкретной задачи я описывал
Конкретную цитату пожалуйста.
R>Closures есть везде (и в тикле и в перле и даже в питоне) и передавать их можно куда угодно,
Еще раз прошу изобразить приведенный мной пример с использованием Tcl/Tk, Perl или Python с использованием их closures.
R>а лисп — не менее императивный язык, чем руби и синтаксиса у лиспа нет вообще никакого. Ни птичьего ни земноводного.
. В той же ветке была наглядно продемонстрирована императивность лиспа. А так же и то, что на Лиспе не было сделано ни одного рещения исходной задачи (где нужно было парсить XML).
R>>>То есть вы — администратор-теоретик?
E>>Нет, я программист-практик. Причем, программист-камиказде, который умудряется встревать в безнадежные проекты. И очень часто приходится выполнять сразу множество ролей: и аналитика, и архитектора, и тестировщика, и документатора. А иногда и внедрением, и обслуживанием приходилось заниматься.
R>Замечательно. Опыта управления нет. Опыта участия в действительно больших проектах нет. Советов по теме — целый воз.
Ага, воинствующее невежество.
Кстати, 200 тысяч строк на C++, три года разработки и сопровождения, три релиза, один разработчик -- это маленький проект?
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Мне больше делать чтоли нечего?
R>>Вы сказали, что в случае трех языков — Tcl, Perl и Python — выбор должен пасть на питон. R>>Я спрашиваю — почему. E>Я ничего не утверждал. Прочитайте внимательно: E>
E>Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
Ну, и где я неправильно прочитал?
R>>Разумеется, претензии к синтаксису не являются ответом на вопрос.
E>А для меня являются. Может быть с научных позиций это совершенно бессмыслено, но я говорю про практику, про то, что мне этот язык придется использовать. И если мне нужно писать set вместо =, и префиксовать каждую переменную $, то я лучше поищу язык, где этого делать не нужно.
Вы вообще внимательно читаете то, что вам пишут?
R>>Closures есть везде (и в тикле и в перле и даже в питоне) и передавать их можно куда угодно,
E>Еще раз прошу изобразить приведенный мной пример с использованием Tcl/Tk, Perl или Python с использованием их closures.
Еще раз не буду ничего изображать. Зачем мне это?
R>>а лисп — не менее императивный язык, чем руби и синтаксиса у лиспа нет вообще никакого. Ни птичьего ни земноводного. E>Про "птичесть" лиспа, это отсюда
. В той же ветке была наглядно продемонстрирована императивность лиспа. А так же и то, что на Лиспе не было сделано ни одного рещения исходной задачи (где нужно было парсить XML).
Я не понял, к чему это?
По ссылке бред какой-то.
Вам не нравятся reader macros по умолчанию? переопределять не пробовали?
Про XML — вообще без комментариев.
R>>Замечательно. Опыта управления нет. Опыта участия в действительно больших проектах нет. Советов по теме — целый воз. E>Ага, воинствующее невежество. E>Кстати, 200 тысяч строк на C++, три года разработки и сопровождения, три релиза, один разработчик -- это маленький проект?
Знаете, reductor, у вас продолжает проявляться неприятная привычка игнорировать конкретные вопросы и просьбы предоставить конкретный пример кода. Причем, проявляется это не только в разговорах со мной, но и с беседах с Cyberax и VladD2. Очень жаль, но в таком русле нельзя вести разговор дальше.
E>>Я ничего не утверждал. Прочитайте внимательно: E>>
E>>Например, вместо одновременного использования Tcl/Tk, Perl и Python лучше выбрать один Python.
R>Ну, и где я неправильно прочитал?
Ключевое слово "например". С таким же успехом можно было написать "например, лучше выбрать Perl" или "например, лучше выбрать Tcl/Tk". Важен не конкретный выбор, а то, что из группы похожих языков (языков из одной целевой ниши), следует остановиться всего на одном, а не тянуть в проект все сразу.
R>>>Closures есть везде (и в тикле и в перле и даже в питоне) и передавать их можно куда угодно,
E>>Еще раз прошу изобразить приведенный мной пример с использованием Tcl/Tk, Perl или Python с использованием их closures.
R>Еще раз не буду ничего изображать. Зачем мне это?
Затем, что я стоял перед конкретной задачей, которую мне нужно было решить за максимально короткое время. Я ее решил с помощью Ruby. Когда мне начинаю намекать на неверный выбор, хотелось бы увидеть, как это можно сделать на других языках. В целях самообразования. И если вы не можете привести пример, то мне не остается ничего другого, как относиться к вашим словам как "собака лает, караван идет" (hint: в роли каравана я вижу себя).
R>>>а лисп — не менее императивный язык, чем руби и синтаксиса у лиспа нет вообще никакого. Ни птичьего ни земноводного. E>>Про "птичесть" лиспа, это отсюда
. В той же ветке была наглядно продемонстрирована императивность лиспа. А так же и то, что на Лиспе не было сделано ни одного рещения исходной задачи (где нужно было парсить XML).
R>Я не понял, к чему это?
К тому, что обсуждения в топике "Следующий язык программирования" шло вскоре после тем "Metaprogramming et al" и "Lisp". И постоянные читатели RSDN были в курсе, откуда взялся термин "птичий".
R>Про XML — вообще без комментариев.
E>>Кстати, 200 тысяч строк на C++, три года разработки и сопровождения, три релиза, один разработчик -- это маленький проект?
R>Это вообще не проект.
Ok. Значит я постараюсь продолжать зарабатывать себе и своей семье на жизнь такими "не проектами". В качестве ремарки: был у меня опыт работы в крупной оффшорной компании, где проекты были большие, народу было много, а кода каждый отдельный разработчик писал меньше. И мне показалось, что для работы в подобных условиях (пятым винтиком в шестой шестеренке с перспективами дальнейшего продвижения по карьерной леснице) нужен другой склад характера и отношение к работе, чем у меня. Так уж сложилось, что я всегда работал на небольших проектах (по вашим меркам), но зато практически во всех ролях одновременно. До сих пор получалось. Не вижу причин для смены курса.
Закончить обсуждение темы с вами я бы хотел очередным оффтопиком, прошу прощения у всех, кого это раздражает.
<offtopic>
Был у меня друг детства, который боксом серьезно занимался и таскал меня с собой на разные соревнования. Там мне многократно приходилось наблюдать одинаковую картину. Выходят на ринг два пацана (лет по 12-13), один технарь, несколько лет занятий боксом, форма отглажена, сам отутюженный и холеный. Сразу видно, фаворит. Другой, обычно, невзрачный, из каких-нибудь "Трудовых резервов", занимается всего пару месяцев в каком-то разбитом зале на окраине. Умеет всего пару прямых в голову и, в лучшем случае, двойку левый-правый прямой. Ну и начинается. В первом-втором раунде фаворит-технарь творит все что хочет, порхает по рингу как бабочка, жалит как пчела, разбивает противника в кровь, сам практически не пропускает. А вот в третьем раунде все меняется. Дыхалки фавориту не хватает, ручки устали, вместо бабочки по рингу движется дохлая муха, дистанция не удерживается, углы оказываются на каждом шагу. А противник прет, ему терять нечего, а победить хочется. И он постоянно левой-правой, левой-правой, опять левой, опять правой. И злость и отчаяние ему силы придают. В результате оба стоят одинаково разбитые, но побеждает как раз не фаворит. Потому что желания у него меньше было, а техника -- это всего лишь техника, она ничего не решает.
</offtopic>
Вот и разговоры с вами, reductor, мне напоминают такие бои. Ваши разговоры про знания языков и прочее -- это как бой с тенью перед зеркалом. Красиво, технично и, безусловно, полезно. Только это -- всего лишь техника, а она ничего не решает. Решают характер и воля к победе. Не знаю, как большие проекты, а упешно завершившиеся безнадежные проекты, в которых мне повезло участвовать -- они все были успешными именно из-за характера и воли к победе разработчиков.
За сим раскланиваюсь и оставляю вас демонстрировать свою технику и знания другим читателям.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
R>>Мне больше делать чтоли нечего? E>Знаете, reductor, у вас продолжает проявляться неприятная привычка игнорировать конкретные вопросы и просьбы предоставить конкретный пример кода. Причем, проявляется это не только в разговорах со мной, но и с беседах с Cyberax и VladD2. Очень жаль, но в таком русле нельзя вести разговор дальше.
Простите, я вам что-то должен?
R>>>>Closures есть везде (и в тикле и в перле и даже в питоне) и передавать их можно куда угодно,
E>>>Еще раз прошу изобразить приведенный мной пример с использованием Tcl/Tk, Perl или Python с использованием их closures.
R>>Еще раз не буду ничего изображать. Зачем мне это?
E>Затем, что я стоял перед конкретной задачей, которую мне нужно было решить за максимально короткое время. Я ее решил с помощью Ruby. Когда мне начинаю намекать на неверный выбор, хотелось бы увидеть, как это можно сделать на других языках. В целях самообразования. И если вы не можете привести пример, то мне не остается ничего другого, как относиться к вашим словам как "собака лает, караван идет" (hint: в роли каравана я вижу себя).
Ну если доходит до такого хамства, то намекну, что это вы здесь лаете и пропагандируете антиинтеллектуализм. Что учиться не надо, а надо работать. И делаете заявления о превосходстве одного языка над другим. Не утруждая себя даже тем, чтобы просто прочитать доккументацию.
А код сами пишите, если интересно. Мне — нет. И я здесь о преимуществах одних языков над другими речи не заводил.
Тем более не рассуждал о тех языках, которых даже не знаю.
E>>>Кстати, 200 тысяч строк на C++, три года разработки и сопровождения, три релиза, один разработчик -- это маленький проект?
R>>Это вообще не проект.
E>Ok. Значит я постараюсь продолжать зарабатывать себе и своей семье на жизнь такими "не проектами". В качестве ремарки: был у меня опыт работы в крупной оффшорной компании, где проекты были большие, народу было много, а кода каждый отдельный разработчик писал меньше. И мне показалось, что для работы в подобных условиях (пятым винтиком в шестой шестеренке с перспективами дальнейшего продвижения по карьерной леснице) нужен другой склад характера и отношение к работе, чем у меня. Так уж сложилось, что я всегда работал на небольших проектах (по вашим меркам), но зато практически во всех ролях одновременно. До сих пор получалось. Не вижу причин для смены курса.
Зато видите причины для того, чтобы делать заявления о том, чего не знаете.
E>Вот и разговоры с вами, reductor, мне напоминают такие бои. Ваши разговоры про знания языков и прочее -- это как бой с тенью перед зеркалом. Красиво, технично и, безусловно, полезно. Только это -- всего лишь техника, а она ничего не решает. Решают характер и воля к победе. Не знаю, как большие проекты, а упешно завершившиеся безнадежные проекты, в которых мне повезло участвовать -- они все были успешными именно из-за характера и воли к победе разработчиков.
Ну если вы так уже на личности переходите, то единственную волю, которую я вижу в вас — это желание знать как можно меньше, а кричать как можно громче.
Если ваш опыт такой же, как и ваши знания, то все становится еще комичнее.
Здравствуйте, reductor, Вы писали:
R>Ну если доходит до такого хамства, то намекну, что это вы здесь лаете и пропагандируете антиинтеллектуализм. Что учиться не надо, а надо работать.
Хотелось бы еще задать один вопрос не по теме. Можно ли где-нибудь взглянуть на ваше явное или косвенное "портфолио"?
