Oberon space
General Category => Общий раздел => Тема начата: valexey от Апрель 03, 2011, 12:07:49 am
-
Внезапно наткнулся на неизвестное мне интервью Бьерна Страуструпа:
http://msdn.microsoft.com/ru-ru/magazine/cc500572.aspx
Несколько цитат:
Говард Дайеркинг Почему языки программирования связаны с людьми на таком глубоком уровне — существуют целые сообщества приверженцев языка?
Бьерн Страуструп Вам лучше спросить психолога, социолога или даже экономиста, а не специалиста по компьютерам. Мне кажется, что языки, используемые нами для выражения своих идей, становятся частью нас самих, поэтому если вы знаете только один язык, может казаться, что сторонники других языков представляют опасность лично для вас. Представляется, что выходом из этой ситуации является изучение других языков. Я сомневаюсь, что можно быть профессионалом в области программного обеспечения и знать только один язык программирования. Может быть и экономическая причина: фундаментальные значения, в отличие от множества практических навыков, выходят за границы языка программирования. Поэтому если я знаю только язык X и его наборы инструментов, а вы являетесь сторонником языка Y и его набора инструментов, вы представляете угрозу для источника моего существования. И снова решением, как мне кажется, является знание нескольких языков и наборов инструментов (а также основных принципов). К сожалению, мои предлагаемые решения не учитывают, что у большинства людей остается совсем немного времени после выполнения всего, что они считают необходимым. Хотя это не оправдание для фанатизма.
ГД Что вы думаете о том, чтобы сделать основной функцией языка передачу сообщений, а не вызов методов?
БС Мне нравится явная передача сообщений, но я использовал ее последний раз уже давно и в контексте распределенных систем. В действительности, чтобы это работало повсеместно, необходимо проделать большую работу с языком и поддержкой инструментов для передачи сообщений. Не думаю, что это уже сделано, но я могу ошибаться. Множество проблем, связанных с общим доступом и блокированием, устраняется, если опираться на сообщения и очереди сообщений. Мне бы хотелось, чтобы это было реализовано с помощью стандартной библиотеки C++, и я в скором времени смогу получить ее (в течение нескольких лет).
ГД Не слишком ли большое значение мы придали архитектуре?
БС Нет, по крайней мере не ее определению. Напротив, архитектуре уделяется слишком мало внимания, и слишком много кода плохого качества с недостаточным пониманием структурных принципов. Я полагаю, что главная проблема архитектуры заключается в том, что многие программисты плохо представляют, что такое хороший код. Одной только способности распознать такой код недостаточно. Наличия правил, определяющих, чего не следует делать, недостаточно. Необходимы ясно сформулированные прескриптивные правила.
ГД Вы можете назвать какие-нибудь собственные практические правила для создания программного обеспечения?
БС Сосредоточьтесь на ключевых концепциях; сосредоточьтесь на их интерфейсе; сосредоточьтесь на управлении ресурсами (память, файлы, блокировки и т.д.); сосредоточьтесь на обработке ошибок. Создание успешных вариантов для классов и Получение ресурса есть инициализация (RAII) – ключевые методы.
ГД Видите ли вы метаданные языка в качестве основы будущих языков программирования?
БС Нет. Нетривиальное использование метаданных кажется мне слишком неудобным.
Ну и еще кусочек:
Но были и приятные сюрпризы. Наиболее яркий – широкое распространенное использование деструкторов в методах, относящихся к управлению ресурсами и обработке ошибок (с помощью исключений). Я знал, что деструкторы были хорошей идеей — в конце концов, приходится полностью менять эффект конструктора — но я не в полной мере осознавал их ключевую роль в успешном использовании C++.
-
Внезапно наткнулся на неизвестное мне интервью Бьерна Страуструпа:
http://msdn.microsoft.com/ru-ru/magazine/cc500572.aspx
Несколько цитат:
БС Мне нравится явная передача сообщений, но я использовал ее последний раз уже давно и в контексте распределенных систем. В действительности, чтобы это работало повсеместно, необходимо проделать большую работу с языком и поддержкой инструментов для передачи сообщений. Не думаю, что это уже сделано, но я могу ошибаться. Множество проблем, связанных с общим доступом и блокированием, устраняется, если опираться на сообщения и очереди сообщений. Мне бы хотелось, чтобы это было реализовано с помощью стандартной библиотеки C++, и я в скором времени смогу получить ее (в течение нескольких лет).
Страуструп не слышал про Эрланг?
-
ГД Какой должна быть роль интегрированной среды разработки в сфере разработки программного обеспечения? Как среда IDE должна поддерживать язык?
БС Я не являюсь активным пользователем IDE. Я высоко ценю быстро реагирующий редактор IDE, который понимает язык, но для меня также необходима возможность работы без IDE. У меня было бы другое мнение, если бы существовала универсальная доступная удовлетворительная среда IDE — в действительности – часть языка или наоборот
Вот!!! Он опять говорит, что среда должна строится не вокруг текстового редактора, в на основе семантического! Первый раз я у него это прочитал в "Эволюции..."
-
Страуструп не слышал про Эрланг?
Эрланг - только язык, а не служба сообщений. Но можно говорить, конечно, о том же AMQP и RabbitMQ (который на Эрланге как раз и написан).
-
Но поскольку C++ создан на основе языка программирования C (и может компилировать существующие программы на C), он смог обеспечить широкое распространение абстракций объектно-ориентированного мышления.
Сегодня уже точно видно, что он смог обеспечить: продлить срок профессиональной жизни для программистов с "кашей в голове" лет эдак на 20, позволив им кое-как использовать ООП, кое-как обеспечивать архитектуру крупных систем... в общем, язык стал спасением для коекакеров :) Я не говорю, что сам язык "коекакерный", Страуструп вложил много труда и проектирования, чтобы сделать такой продукт... пригодный для "коекакерства" :) Поэтому и для серьёзных профессионалов он тоже всегда был пригоден... Когда у них не было возможности выбрать для работы что-нибудь другое.
Вот и сам Бьярн признаёт:
Универсальный язык ограничен не только необходимостью поддержки различных пользователей, но также и понятности для больших групп пользователей с различными допущениями и уровнем образования (основные принципы должны быть пригодными к использованию школьниками с плохим уровнем обучения).
-
Вообще, интервью Страуструпа всегда любопытны.
Только перевод тут отвратный.
-
Вот оно, в точку:
Меня беспокоит количество языков, которые создаются, реализуются и представляются невероятно помпезно, а затем они исчезают, не оказав какого-либо существенного влияния. В течение всего этого времени — обычно в течение длительного многолетнего процесса разработки — для нового языка требуются значительные ресурсы, тогда как результаты этого процесса практически отсутствуют. Я написал статью об этом явлении под названием "A Rationale for Semantically Enhanced Library Languages" (research.att.com/~bs/SELLrationale.pdf) (Разумное объяснение языков с семантически улучшенной библиотекой). Я отстаиваю использование библиотек, возможно, поддерживаемых инструментами, и универсального языка.
-
Вообще, всегда, когда читаю Страуструпа, соглашаюсь со многими его положениями, и уже давно вижу, что отличная реализация этих положений - именно Компонентный Паскаль. За исключением этой обратки с Сями.
-
Страуструп не слышал про Эрланг?
Эрланг - только язык, а не служба сообщений. Но можно говорить, конечно, о том же AMQP и RabbitMQ (который на Эрланге как раз и написан).
Не смог понять, что Вы имеете в виду.
Пересылка сообщений из процесса в процесс -- самая важная фишка Эрланга. При чём здесь софт, написанный на Эрланге?
-
Вообще, всегда, когда читаю Страуструпа, соглашаюсь со многими его положениями, и уже давно вижу, что отличная реализация этих положений - именно Компонентный Паскаль. За исключением этой обратки с Сями.
Так что же не даёт Страуструпу дойти до Компонентного Паскаля, раз он так подходит под его требования (ну кроме малокритичной совместимости с сями)?
-
Пардон, я при беглом прочтении заметил в Вашей цитате Страуструпа слово "распределённые" и высказался про этот случай.
А касательно КП - что тут непонятного. Страуструп живёт в другой экосистеме, и в рамках других инженерных подходов. Чтобы понять КП, надо на КП работать. Несколько лет. И не только в режиме "вместо Дельфи или Явы", а и для системных задач. Так же, как на С++ до сих пор народ пишет как на "Си с фичами", и немногие используют его в том стиле, как задумывал Страуструп.
Страуструп отлично чувствует требования и реалии некоторого класса задач, вот я про что. И учитывал эти реалии в своём языке он достаточно вдумчиво, просто... просто не упростил всё и слишком большой букет одновременно пытался обеспечить.
-
Пардон, я при беглом прочтении заметил в Вашей цитате Страуструпа слово "распределённые" и высказался про этот случай.
В языке ерланг как раз в том числе и распределенная рассылка сообщений, и не надо для этого никаких кроликов изобретать, это все есть сразу и из каробки. Там же совершенно без разницы где получатель сообщения находится, здесь или за тысячу километров.
-
Как ИТ-специалист Бьерн Страуструп полностью дискредитировал себя в моих глазах.
Интервью я не читал.
-
Как ИТ-специалист Бьерн Страуструп полностью дискредитировал себя в моих глазах.
Интервью я не читал.
О! Классическое, стопроцентное "не читал, но осуждаю".
-
Универсальный язык ограничен не только необходимостью поддержки различных пользователей, но также и понятности для больших групп пользователей с различными допущениями и уровнем образования (основные принципы должны быть пригодными к использованию школьниками с плохим уровнем обучения).
Вот тут большой вопрос.
ак и самолеты, языки бывают разными. Летчиков учат на учебных спмолетах, хотя принципы полета - одинаковые. И только опытные летчики летают на больших Боингах и/или боевых истребителях.
Поэтому использовать один и тот же "самолет" для школьников и для профи - БОЛЬШАЯ ошибка.
-
О! Классическое, стопроцентное "не читал, но осуждаю".
Я дал свою оценку самому Бьерну Страуструпу, а не его интервью. Моё мнение о Б.Страуструпе сформировалось задолго до этого интервью. Той информации, которую я узнал о нём ранее, вполне хватило.
-
О! Классическое, стопроцентное "не читал, но осуждаю".
Я дал свою оценку самому Бьерну Страуструпу, а не его интервью. Моё мнение о Б.Страуструпе сформировалось задолго до этого интервью. Той информации, которую я узнал о нём ранее, вполне хватило.
Не, оценку ему ты не дал, ты просто высказал своё фи :-)
Так что прошу таки дать оценку.
-
Не, оценку ему ты не дал, ты просто высказал своё фи :-)
Да, можно и так назвать. Я сказал только то, что хотел сказать. ;)
-
Так что прошу таки дать оценку.
Я приведу маленькую цитату Б.Страуструпа из его книги, а ты уж сам дай ему оценку.
В С существуют свои проблемы, но в языке, разрабатываемом "с нуля" они появились бы тоже, а проблемы С, по крайней мере, хорошо известны.
По-моему, это полный нонсенс. :(
-
Так что прошу таки дать оценку.
Я приведу маленькую цитату Б.Страуструпа из его книги, а ты уж сам дай ему оценку.
В С существуют свои проблемы, но в языке, разрабатываемом "с нуля" они появились бы тоже, а проблемы С, по крайней мере, хорошо известны.
По-моему, это полный нонсенс. :(
Книга большое Г. (по крайней мере, первые переводы были практически нечитаемы, и поражали большим количеством ошибками всех мастей). На мой взгляд, Бьерн Страуструп - типичный пример "программиста -паяльника ", со всеми вытекающими последствиями (низкий уровень интеллекта). Однако, это еще не значит что в своей (узкой) области он не является спцецом экстра класса...
-
Так что прошу таки дать оценку.
Я приведу маленькую цитату Б.Страуструпа из его книги, а ты уж сам дай ему оценку.
В С существуют свои проблемы, но в языке, разрабатываемом "с нуля" они появились бы тоже, а проблемы С, по крайней мере, хорошо известны.
По-моему, это полный нонсенс. :(
А что, он разве не прав? Разве при разработке нового языка не возникает новых проблем? Возникают. Взять тот же оберон с его with.
А проблемы в Си они не то что хорошо известны, они обходятся давно подавляющим большенством просто на уровне рефлексов. То есть при написании программы просто невозможно (если специально сильно не стараться) наступить на эти грабли. Собственно практика это подтверждает. На моей памяти был ровно один случай, когда из за особенности именно Сей/Плюсов мы потеряли где-то полчаса времени на поиск ошибки.
-
Да, но Страуструп похоже когда это говорил, не учитывал важность создания интеллектуальных IDE и прочего инструментария разработчика, который должен как-то анализировать и трансформировать код. Собственно это один из трех китов, на которых стоят java и c#.
-
А что, он разве не прав? Разве при разработке нового языка не возникает новых проблем? Возникают. Взять тот же оберон с его with.
А проблемы в Си они не то что хорошо известны, они обходятся давно подавляющим большенством просто на уровне рефлексов. То есть при написании программы просто невозможно (если специально сильно не стараться) наступить на эти грабли. Собственно практика это подтверждает. На моей памяти был ровно один случай, когда из за особенности именно Сей/Плюсов мы потеряли где-то полчаса времени на поиск ошибки.
В том то и дело, что ОН ПРАВ (но крайне однобоко) :)
-
А вот эта фраза меня чуть не довела до истерики: ;D
При разработке языка С++ одним из важнейших критериев выбора была простота.
Странно слышать такое от автора самого сложного языка программирования в мире.
-
А вот эта фраза меня чуть не довела до истерики: ;D
При разработке языка С++ одним из важнейших критериев выбора была простота.
Странно слышать такое от автора самого сложного языка программирования в мире.
С++ не самый сложный ЯП в мире.
-
С++ не самый сложный ЯП в мире.
По-крайней мере, один из самых сложных. "Почётное" второе или третье место ничего не меняет.
-
С++ не самый сложный ЯП в мире.
По-крайней мере, один из самых сложных. "Почётное" второе или третье место ничего не меняет.
А кстати, в чем сложность будем мерять? :-)
-
К слову сказать, сложность языка никого не волнует и не интересует, всех волнует и интересует насколько сложно данную задачу решить на данном языке.
-
А кстати, в чем сложность будем мерять? :-)
Вот частное мнение (http://www.codenet.ru/progr/cpp/ccpp.php):
Бьерн Страуструп не только пошел по пути усложнения компилятора, но и по пути усложнения языка программирования, так что изучение C++ это очень долгосрочный процесс и, наверное, на сегодняшний день это самый сложный язык программирования.
Далее, я не буду доказывать, что С++ один из самых сложных языков. Если хочешь, можешь заняться доказательством обратного. ;)
-
Это самое частное мнение ничуть не более ценно нежели мнение твоё. Не интересно.
-
К слову сказать, сложность языка никого не волнует и не интересует, всех волнует и интересует насколько сложно данную задачу решить на данном языке.
Волнует , меня и многих преподавателей в средней и высшей школы ;)
-
А вот эта фраза меня чуть не довела до истерики: ;D
При разработке языка С++ одним из важнейших критериев выбора была простота.
Странно слышать такое от автора самого сложного языка программирования в мире.
На Бьярна можно "наезжать" - но зачем? Он честен, был когда давал это интервью, писал книгу, разрабатывал С++... Какой смысл требовать "с козла молока"? (Он не Вирт, далеко не Вирт, далее в отличие от коровцев он никогда не поучал...). :(
-
Какой смысл требовать "с козла молока"?
Точно! :)
-
Даже не интересно отвечать. ;D
Не интересно.
Мелкая "месть"? :D
-
Даже не интересно отвечать. ;D
Не интересно.
Мелкая "месть"? :D
Неа, оно не связано. :-) Но желающие могут конечно связать. Узлом.
-
К слову сказать, сложность языка никого не волнует и не интересует, всех волнует и интересует насколько сложно данную задачу решить на данном языке.
На самом деле, зря волнует. Большинство программистов сталкивается не с реально сложными задачами, а с большим количеством простых либо с простыми большого объёма. Либо сами себе делают сложности (не упрощают постановки задач, как следует).
Поэтому гораздо важнее - для качества основной массы софта - насколько качественно и продуктивно программисты решают обычные, повседневные задачи. Насколько качественно делается каждый болтик-компонентик.
-
Мелкая "месть"? :D
Неа, оно не связано. :-)
Это понятно. Потому у меня там и смайлик развесёлый. :)
-
К слову сказать, сложность языка никого не волнует и не интересует, всех волнует и интересует насколько сложно данную задачу решить на данном языке.
На самом деле, зря волнует. Большинство программистов сталкивается не с реально сложными задачами, а с большим количеством простых либо с простыми большого объёма. Либо сами себе делают сложности (не упрощают постановки задач, как следует).
Поэтому гораздо важнее - для качества основной массы софта - насколько качественно и продуктивно программисты решают обычные, повседневные задачи. Насколько качественно делается каждый болтик-компонентик.
Я имел ввиду Задачу, а не подзадачи на которые она в последствие разбивается. Задача это, например, сделать некую штуку, которая бы управляя ракетой, сделала бы так, чтобы ракета прилетела бы туда куда нужно. А уж какая эта будет штука -- вопрос абсолютно десятый. Возможно этой штукой будет прапорщик Вася, сидящий в этой ракете и дергающий за веревочки. В этом случае, идеальным языком для решения задачи возможно окажется русский матерный. А уж какие именно подзадачи по прокладке веревочек, и запихиванию Васи в ракету там будут решаться и как именно -- вопрос абсолютно десятый.
-
Ну да, но почему тогда "всех волнует"?
Главных конструкторов и системных архитекторов на порядок меньше, чем разработчиков.
-
Ну да, но почему тогда "всех волнует"?
Главных конструкторов и системных архитекторов на порядок меньше, чем разработчиков.
Ну, во первых, плох тот солдат, что не мечтает стать генералом :-)
А во вторых, ты забываешь, что полно проектов делается малыми коллективами в малые сроки, очень часто вообще одним человеком, и тогда тут каждый сам себе архитектор и генеральный конструктор. То есть народу в таких проектах суммарно как минимум не меньше, а скорее всего болше чем в больших проектах где есть отдельный отдел архитектуры и так далее.