AVK>Этика очень простая — говори об объекте спора,а не о субъекте и все будет хорошо. А когда в последнее время все топики с твоим участием, которые попадались мне на глаза, обязательно переходят в выяснение какой возраст у собеседника и какая у него квалификация, это сложно расценивать иначе как неспособность к конструктивному спору.
Ну а что делать, если сталкиваешься с собеседником, который дейтсвительно сечёт в некоей узкой области, интересной так же и мне, но при этом с ходу посылает всех пойти книжки почитать? Мне в принципе пофиг как подобных клиентов разболтать. В топике про обсуждение стека IP как раз попытался. Жаль что вместо обсуждения характеристик протоколов клиент все время проваливался в обсуждение отдельных технических моментов реализации одного протокола, т.е. ни сравнения протоколов, ни обсуждения их характеристик в упор не получалось. Поэтому я обсуждать ничего далее не стал, а завершил свое участие готовым мнением без обсуждения. Одно плохо — этому мнению хрен знает сколько лет, а "обкатать" его не на ком. Спецы по IP обычно являются фанатами IP, что снижает полезность обсуждения.
Ну а в топике про НКА просто взорвался, надо признать, в ответ на очередное "что-то вы ничего не знаете"... сговорились все что-ли
После подобного действительно сложно быть способным к конструктивному спору, грешен. Обычно возвращаю тем же, с тем отличием, что называю конкретные темы/технологии, вместо абстрактного "пойди-ка почитай".
Вообще, манерой отсылать оппонента к учебникам страдает весь технический рунет. Есть такое. Не могу представить подобное развитие спора на западных сайтах.
(Поэтому последние месяцы почти не участвую в технических форумах, ибо настроение может попортиться быстрее, чем от "политики")
AVK>А ты не задумывался о том, что причина не в недостатке опыта (уж поверь, мое окружение весьма разнообразно в плане используемых технологий), а в том, что статически типизированные языки дают то самое ощущение надежности уже после компиляции (а то и до нее)?
Да вроде, пару лет назад именно так и говорил, когда было очередное С++ vs .Net. Ибо в 1.1 с типизированностью траблы. Однако же, ты и Влад находили аргументы, которые "пересиливали" аргумент жестокой статической типизации.
AVK>Разумеется, так получается не всегда. К сожалению, никакие языковые средства не позволяют устранить неопределенность окружения, о чем я с самого начала и написал. Однако если такового окружения нет, постоянные попытки компилировать и отлаживать микрокусочки корда довольно серьезно снижают суммарную производительность и осложняют проектирование, поскольку рефакторить вроде бы отлаженный софт становится жалко.
Нет, речь не столько о микродроблениях отладки (ибо такое дробление вряд ли нужно), а о том, что в отладку легко переключиться в произвольный момент готовности проекта. Вот пишу код, например, в чем-то засомневался... "а ну-ка, ну-ка", пару раз по нему тут же проехался отладкой, прояснил что-то, сделал как надо, и забыл.
Согласен, разумеется с аргументом из прошлого поста, что Рефлектор помогает и немало. Я когда-то толком разобрался с MFC и OLE, когда получил наконец тот самый дистрибутив шестерки, где исходники библиотек были.
Да, наверно, в половине случаев достаточно засунуть нос в рефлектор, а не ставить эксперименты. (Хотя, обфускированный CrystalReport хачил именно через "игры")
AVK>Ну и отсуствие мощных средств автоматизированного рефакторинга в языках без статической типизации довершает безрадостную картину programming by example.
Ну я как бы за применение предмета обсуждения именно в новых языках.
Споримть мне влом, так что я выскажусь и пойду по по свои делам. Так что не обесудь.
Так вот. По-моему, скорость, простота, доступность и интерактивность отладки очень важны. Враньем является то что нормально когда кто-то не компилируется неделями. Да это возможно, но все же это большое интеллектуальное и моральное напряжение.
Так же несомненно, что качественная статическая типизация в купе с типобезопасностью и грамотным компилятором позволяют контролировать огромную часть ошибок до запуска программы и тем самым повышают ее надежноть, делают возмоным проводить более длинные циклы "придумал/написал/запусти/отладил" нежели в динамических языках, что в свою очередь дает возможность решать более сложные и отвественные задачи.
Но для работы важны и тонны других факторов таких как читабельность написанного, а значит уровень языка, возможнсть автоматизированного рефакторинга, безопасность языка, удобство редактора и IDE и многогое, многое другое.
Так вот диначиеческие языки несомненно выигрывают в том плане, что цикл "придумал/написал/запусти/отладил" у них самый короткий из имеющихся. С++ несомненно в полной зандице практически по всем характеристикам (только битовыжимание и оптимизация использования памяти на его стороне). Но уже начиная с Явы мы имеем отличнейшую подборку важных характеристик. C# и т.п. имеют только лучший набор характеристик.
Так вот на мой взгляд интерактивности C# более чем достаточного для максимально эффективной разработки современного софта. Зато другие его характеристики на сегодня резко обходят анлогичные у скриптовых языков. Если же не ограничиваться популярными языками, а вспомнить о том, что у нас на сегодня есть Nemerle и Scala, которые по уровню и выразительности значительно обходят лучие представителей скриптового мира, то о чем вообще речь я даже понять не могу. Скрипты — это явно т тупиковая ветвь эволюции. Единственный нужный скрпит, на мой взгляд, это скрипт командной строки.
Учитывая, что процессорные мощности будут только расти интерактивность разработки на статически типизированных языках будет так же расти. Так же будут улучшаться и увеличиваться в объеме другие полезные средства ускорения разработки и повышения ее уровня.
Так что мой прогноз такой. Скрипты все больше и больше будут проигрывать.
Популярность криптов, на мой взгляд, связана с тем, что они появились как альтернатива весма ограниченным языкам вроде С/С++, Фортрану.
Возможно я не прав в том плане, что скрипты позволяют (или создают такую иллюзию) на первых порах меньше думать о том что и как делается. Но при повышении сложности задач это приемущество постепенно превращается в недостаток.
Динамика же никуда не исчезает. Она есть в статических языках. Некоторые, вроде Васика, вообще позволяют переключаться на дикамику в конкретных местах программы (но что-то не видено восхищенных слов по этому поводу). Ну, а я лично предпочитаю компонентынй подход который при всей свой динамичности позволяет не отказываться от статической типизации.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
[зверьковыгрызено]
VD>Возможно я не прав в том плане, что скрипты позволяют (или создают такую иллюзию) на первых порах меньше думать о том что и как делается. Но при повышении сложности задач это приемущество постепенно превращается в недостаток.
В целом, все это довольно занятно (и, видимо, по большей части верно).
Впрочем, интересно завернуть вопрос вот в какую сторону — в сторону "повышения сложности" как концепции.
Ну, с софистикой в духе "есть 2 способа написать программу без ошибок: настолько простую, что места для ошибок не будет; настолько сложную, что ошибки не будут заметны" мы все знакомы. Впрочем, я далек от того, чтобы утверждать, что мол "сложные программы только у плохих программистов". Мне просто интересно обсудить, где действительно сложность (тем паче — повышающаяся с каждым днем сложность) необходима в сегодняшней индустрии программирования.
Чисто теоретически, "оправданная сложность" может оправдываться:
1. Сложностью алгоритма (какое-то безумно сложное криптование, хитровыдуманная обработка огромных массивов информации).
2. Сложностью обслуживаемого процесса (напр.бизнес-процесса, когда в предметной области настолько дофига объектов/субъектов и отношений между ними, что "по-другому не запрограммируешь").
3. ???
Идея моя в том, что во всех случаях, кроме перечисленных (хоть я, возможно, и не все перечислил) набор простейших "однозадачных" модулей, слабосвязанных в нескольких точках, лучше с любой точки зрения, нежели "монстр-монолит". А для такой архитектуры, возможно (возможно), скрипт, с его "нулевым циклом", может оказаться удобнее, не растеряв особо своих преимуществ (именно из-за отличия "написал-выполнил" vs. "создал проект-создал в нем несколько файлов-настроил пути-исправил ошибки компиляции-скомпилировал-собрал-запустил", оставляя в стороне отличия собственно языков).
(тут, кстати, есть довольно очевидные параллели "unix way — скрипты", "виндовое программирование — компилируемые языки со сложными средствами разработки")
VD>Скрипты — это явно т тупиковая ветвь эволюции. Единственный нужный скрпит, на мой взгляд, это скрипт командной строки.
Для тебя лично скорее всего да.
И вообще скриптование это только один из способов использования динамических языков.
VD>Учитывая, что процессорные мощности будут только расти интерактивность разработки на статически типизированных языках будет так же расти. Так же будут улучшаться и увеличиваться в объеме другие полезные средства ускорения разработки и повышения ее уровня.
Этот же рост процессорных мощностей расширяет клас задач эффектино решаемых динамическими языками, плюс делатет вполне реальными хорошие jit'ы для них.
VD>Так что мой прогноз такой. Скрипты все больше и больше будут проигрывать.
Скрипты точно не будут проигрывать, задачи решаемые скриптами очень мало пересекаются с задачами для статических языков.
А насчет динамических языков сейчас наблюдается тенденция обратная твоим желаниям, их популярность растет.
VD>Популярность криптов, на мой взгляд, связана с тем, что они появились как альтернатива весма ограниченным языкам вроде С/С++, Фортрану.
Динамические языки стали популярны когда ява уже стала очень популярной.
VD>Возможно я не прав в том плане, что скрипты позволяют (или создают такую иллюзию) на первых порах меньше думать о том что и как делается. Но при повышении сложности задач это приемущество постепенно превращается в недостаток.
Тяжело комментировать бессмысленное выражение
Может разъяснишь про иллюзии, и чем они мешают при повышении сложности?
VD>Динамика же никуда не исчезает. Она есть в статических языках. Некоторые, вроде Васика, вообще позволяют переключаться на дикамику в конкретных местах программы (но что-то не видено восхищенных слов по этому поводу). Ну, а я лично предпочитаю компонентынй подход который при всей свой динамичности позволяет не отказываться от статической типизации.
У бейсика безжалостно вырезали самые вкусные вещи из динамики, так что не стоит вспоминость об убогом
Здравствуйте, vdimas, Вы писали:
V>Да вроде, пару лет назад именно так и говорил, когда было очередное С++ vs .Net. Ибо в 1.1 с типизированностью траблы. Однако же, ты и Влад находили аргументы, которые "пересиливали" аргумент жестокой статической типизации.
Нормально в 1.1 с типизацией. Дженерики, при всей их полезности, ничего кардинального (в плане надежности и предсказуемости) в процесс разработки не привнести. Всего лишь подсократил объем ручной работы.
V>Нет, речь не столько о микродроблениях отладки (ибо такое дробление вряд ли нужно), а о том, что в отладку легко переключиться в произвольный момент готовности проекта.
Это зависит от архитектуры, а не от возможностей среды.
V> Вот пишу код, например, в чем-то засомневался... "а ну-ка, ну-ка", пару раз по нему тут же проехался отладкой, прояснил что-то, сделал как надо
Вотя так не делаю, ибо это далеко не самый эффективный способ. Эффективнее всего заранее проектировать так, чтобы необходимости в отладке не было.
V>, и забыл.
А вот это вряд ли. Первый же рефакторинг тебя озаботит всем кодом, который он затрагивает. Для того, чтобы не держать в памяти весь код существует ровно одно средство — снижение связности. А отладка тут скорее с другой стороны баррикад, бо стимулирует на запутанные решения. А уж твое предложение это вобще ужас — если писать код тьак, чтобы тут же о нем забыть, то качество этого кода будет ...
V>Да, наверно, в половине случаев достаточно засунуть нос в рефлектор, а не ставить эксперименты.
Но это, заметь, только в том случае, когда поведение окружения заранее неизвестно. А это далеко не всегда так.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, VladD2, Вы писали:
VD>Так вот. По-моему, скорость, простота, доступность и интерактивность отладки очень важны. Враньем является то что нормально когда кто-то не компилируется неделями. Да это возможно, но все же это большое интеллектуальное и моральное напряжение.
Не совсем так. Это вполне возможно и без напряжения, если данную конкретную задачу Х ты решаешь в 225 раз.
... << RSDN@Home 1.2.0 alpha rev. 646 on Windows XP 5.1.2600.131072>>
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, VladD2, Вы писали:
ЗХ>[зверьковыгрызено]
VD>>Возможно я не прав в том плане, что скрипты позволяют (или создают такую иллюзию) на первых порах меньше думать о том что и как делается. Но при повышении сложности задач это приемущество постепенно превращается в недостаток.
ЗХ>В целом, все это довольно занятно (и, видимо, по большей части верно). ЗХ>Впрочем, интересно завернуть вопрос вот в какую сторону — в сторону "повышения сложности" как концепции.
ЗХ>Ну, с софистикой в духе "есть 2 способа написать программу без ошибок: настолько простую, что места для ошибок не будет; настолько сложную, что ошибки не будут заметны" мы все знакомы. Впрочем, я далек от того, чтобы утверждать, что мол "сложные программы только у плохих программистов". Мне просто интересно обсудить, где действительно сложность (тем паче — повышающаяся с каждым днем сложность) необходима в сегодняшней индустрии программирования.
ЗХ>Чисто теоретически, "оправданная сложность" может оправдываться: ЗХ>1. Сложностью алгоритма (какое-то безумно сложное криптование, хитровыдуманная обработка огромных массивов информации). ЗХ>2. Сложностью обслуживаемого процесса (напр.бизнес-процесса, когда в предметной области настолько дофига объектов/субъектов и отношений между ними, что "по-другому не запрограммируешь"). ЗХ>3. ???
ЗХ>Идея моя в том, что во всех случаях, кроме перечисленных (хоть я, возможно, и не все перечислил) набор простейших "однозадачных" модулей, слабосвязанных в нескольких точках, лучше с любой точки зрения, нежели "монстр-монолит".
Конечно, и в этих 3 случаях также слабосвязанность рулит.
В принципе каждый класс — это и есть минимодуль.
ЗХ> А для такой архитектуры, возможно (возможно), скрипт, с его "нулевым циклом", может оказаться удобнее, не растеряв особо своих преимуществ
Здесь скорее все сводится к философскому выбору:
надежность и компонентность взасчет проверки типизированных интерфейсов или
гибкость взасчет duck typing в динамике.
ЗХ>(именно из-за отличия "написал-выполнил" vs. "создал проект-создал в нем несколько файлов-настроил пути-исправил ошибки компиляции-скомпилировал-собрал-запустил", оставляя в стороне отличия собственно языков).
Вот именно — это не свойство языка, а свойство среды разработки.
Просто для языков со статической типизацией "исправил ошибки компиляции" — это уже отлов ошибок в программе.
Тогда как для динамики это свалится во время исполнения (если выявится сразу).
В остальном все аналогично: "написал-выполнил". Создавать проект и прописывать пути для простых случаев не нужно, а для сложных это оправданно.
P.S. Как я не раз говорил, знаем типы — работает интеллисенс и навигация по коду, и это реально упрощает и ускоряет процесс разработки очень нехило.
VD>Так вот на мой взгляд интерактивности C# более чем достаточного для максимально эффективной разработки современного софта. Зато другие его характеристики на сегодня резко обходят анлогичные у скриптовых языков. Если же не ограничиваться популярными языками, а вспомнить о том, что у нас на сегодня есть Nemerle и Scala, которые по уровню и выразительности значительно обходят лучие представителей скриптового мира, то о чем вообще речь я даже понять не могу. Скрипты — это явно т тупиковая ветвь эволюции. Единственный нужный скрпит, на мой взгляд, это скрипт командной строки.
Это все так и есть, и за скрипты я не агитировал. Просто у меня есть мнение, что в среды разработки для того же C# можно включить некоторые способы, которые автоматом есть для динамических языков (Lisp, SmallTalk или даже нединамический, но очень интерактивный Fort). Сам язык C# вкупе с дотнетом имеет такие характеристики, что написать скрипт-машинку для языка C# мне представляется вполне возможным.
Для примера можно взять VB (не дотнетный, а тот, который последний 6.0). На этапе оладки конкретного проетка он представляет из себя скрипт-машину без ущерба для св-в типизации языка (которое было введено с 4-го VB), после отладки можно скомпиллировать двоичный модуль, получаем вполне оптимизированный двоичный результат.
Мне думается, что пока что MS очень активно разрабатывает новые версии самого языка C#, и просто руки не доходят до разработки полного скриптового аналога текущего варианта. К тому же многие программисты на C# — это скорее бывшие плюсовики/джава-программисты/дельфисты, т.е. люди, которым описанная фича ранее никогда и не нужна была.
VD>Учитывая, что процессорные мощности будут только расти интерактивность разработки на статически типизированных языках будет так же расти. Так же будут улучшаться и увеличиваться в объеме другие полезные средства ускорения разработки и повышения ее уровня.
Ну дай-то бог. А кто мне запрещет говорить "хочу" уже сегодня.
[скипнул про скрипты, ибо не о них речь]
VD>Динамика же никуда не исчезает. Она есть в статических языках. Некоторые, вроде Васика, вообще позволяют переключаться на дикамику в конкретных местах программы (но что-то не видено восхищенных слов по этому поводу).
Угу, что удивительно, что VB для Net обычно умел не меньше, а больше, чем мог C# (сейчас отстает по анонимным делегатам и yield return, например). Но вот история развития языка VB автоматом записывает его любителей в ламеры. В общем, исторически так сложилось, что все наработки MS в обсуждаемом плане оказались с другой стороны IT-сообщества.
Здравствуйте, Андрей Хропов, Вы писали:
ЗХ>>Идея моя в том, что во всех случаях, кроме перечисленных (хоть я, возможно, и не все перечислил) набор простейших "однозадачных" модулей, слабосвязанных в нескольких точках, лучше с любой точки зрения, нежели "монстр-монолит". АХ>Конечно, и в этих 3 случаях также слабосвязанность рулит. АХ>В принципе каждый класс — это и есть минимодуль.
Слабосвязность в некотором роде рулит всегда. Я имел в виду не только ее. Для примера: MS Outlook, если его использовать только как мэйлер, явно "чересчур большая и монолитная" система, которую хрен настроишь и которая падает время от времени из-за разных конфликтов между частями. При этом, сущностей-то там всего ничего, а классов, небось, до хрена
т.е. я ратовал не только за слабосвязность, но и за минимализм сущностей. При этом и говорил, что минимализм может быть невозможен в случае того же 1С — там просто сущностей со множеством слабоочевидных связей такое неимоверное количество, что "по другому не получится".
ЗХ>> А для такой архитектуры, возможно (возможно), скрипт, с его "нулевым циклом", может оказаться удобнее, не растеряв особо своих преимуществ АХ>Здесь скорее все сводится к философскому выбору:
АХ>надежность и компонентность взасчет проверки типизированных интерфейсов или АХ>гибкость взасчет duck typing в динамике.
ЗХ>>(именно из-за отличия "написал-выполнил" vs. "создал проект-создал в нем несколько файлов-настроил пути-исправил ошибки компиляции-скомпилировал-собрал-запустил", оставляя в стороне отличия собственно языков). АХ>Вот именно — это не свойство языка, а свойство среды разработки. АХ>Просто для языков со статической типизацией "исправил ошибки компиляции" — это уже отлов ошибок в программе. АХ>Тогда как для динамики это свалится во время исполнения (если выявится сразу).
АХ>В остальном все аналогично: "написал-выполнил". Создавать проект и прописывать пути для простых случаев не нужно, а для сложных это оправданно.
АХ>P.S. Как я не раз говорил, знаем типы — работает интеллисенс и навигация по коду, и это реально упрощает и ускоряет процесс разработки очень нехило.
В целом, есть две (или более) не вполне ортогональных осей, в которых запуталась эта ветка — "статика-динамика", удобство языка, удобство среды и т.п. Я же говорил только о том, что для "разумно простой системы" аргументы рода "а если у тебя 194 класса, без интеллисенса и проверок на этапе компиляции не обойтись" — могут быть неактуальны.
Здравствуйте, VladD2, Вы писали:
VD>Так вот. По-моему, скорость, простота, доступность и интерактивность отладки очень важны. Враньем является то что нормально когда кто-то не компилируется неделями. Да это возможно, но все же это большое интеллектуальное и моральное напряжение.
+1
VD>Так же несомненно, что качественная статическая типизация в купе с типобезопасностью и грамотным компилятором позволяют контролировать огромную часть ошибок до запуска программы и тем самым повышают ее надежноть, делают возмоным проводить более длинные циклы "придумал/написал/запусти/отладил" нежели в динамических языках,
+1
VD>что в свою очередь дает возможность решать более сложные и отвественные задачи.
+1
VD>Скрипты — это явно т тупиковая ветвь эволюции. Единственный нужный скрпит, на мой взгляд, это скрипт командной строки.
Я думаю что основным преимуществом скриптовых языков является рантайм duck typing или принцип
EAFP (Easier to Ask Forgiveness than Permission). Т.е. полиморфизм без необходимости явно иметь интерфейсы.
В то же время этот подход снижает надежность.
VD>Учитывая, что процессорные мощности будут только расти интерактивность разработки на статически типизированных языках будет так же расти. Так же будут улучшаться и увеличиваться в объеме другие полезные средства ускорения разработки и повышения ее уровня.
VD>Так что мой прогноз такой. Скрипты все больше и больше будут проигрывать.
Пока наблюдается обратная картина.
VD>Популярность криптов, на мой взгляд, связана с тем, что они появились как альтернатива весма ограниченным языкам вроде С/С++, Фортрану.
VD>Возможно я не прав в том плане, что скрипты позволяют (или создают такую иллюзию) на первых порах меньше думать о том что и как делается. Но при повышении сложности задач это приемущество постепенно превращается в недостаток.
Согласен. Но дело в том, что сейчас очень много народнохозяйственных задач достаточно просты (какой-нибудь инет-магазин на стандартных компонентах), вот они и все популярнее.
VD>Динамика же никуда не исчезает. Она есть в статических языках.
По-моему, пока нормально реализовано только в Nemerle (Late binding macro).
Насчет Basicа не знаю.
Впрочем, этого вполне достаточно чтобы иметь это основное (и насколько я представляю, единственное) преимущество динамических языков, когда это оправданно.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Андрей Хропов, Вы писали:
ЗХ>>>Идея моя в том, что во всех случаях, кроме перечисленных (хоть я, возможно, и не все перечислил) набор простейших "однозадачных" модулей, слабосвязанных в нескольких точках, лучше с любой точки зрения, нежели "монстр-монолит". АХ>>Конечно, и в этих 3 случаях также слабосвязанность рулит. АХ>>В принципе каждый класс — это и есть минимодуль.
ЗХ>Слабосвязность в некотором роде рулит всегда. Я имел в виду не только ее. Для примера: MS Outlook, если его использовать только как мэйлер, явно "чересчур большая и монолитная" система, которую хрен настроишь и которая падает время от времени из-за разных конфликтов между частями. При этом, сущностей-то там всего ничего
Ну вот насчет того, что всего-ничего не соглашусь (см. также ниже).
ЗХ>, а классов, небось, до хрена
Но с другой стороны вот Спольcки высказывал такое мнение (здесь):
A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.
Unfortunately, it's never the same 20%. Everybody uses a different set of features. In the last 10 years I have probably heard of dozens of companies who, determined not to learn from each other, tried to release "lite" word processors that only implement 20% of the features. This story is as old as the PC. Most of the time, what happens is that they give their program to a journalist to review, and the journalist reviews it by writing their review using the new word processor, and then the journalist tries to find the "word count" feature which they need because most journalists have precise word count requirements, and it's not there, because it's in the "80% that nobody uses," and the journalist ends up writing a story that attempts to claim simultaneously that lite programs are good, bloat is bad, and I can't use this damn thing 'cause it won't count my words. If I had a dollar for every time this has happened I would be very happy.
When you start marketing your "lite" product, and you tell people, "hey, it's lite, only 1MB," they tend to be very happy, then they ask you if it has their crucial feature, and it doesn't, so they don't buy your product.
И мне кажется что оно имеет под собой основания. А так как MS делает продукты для максимально широкой аудитории и требующие минимальной настройки, то проще нагрузить Outlook редко используемыми фичами, чем кто-то бы сказал, что "этой фичи нет".
Справедливости ради скажу, что у меня никаких проблем с его настройкой и падениями не было.
ЗХ>т.е. я ратовал не только за слабосвязность, но и за минимализм сущностей. При этом и говорил, что минимализм может быть невозможен в случае того же 1С — там просто сущностей со множеством слабоочевидных связей такое неимоверное количество, что "по другому не получится".
Вот то-то и оно, что жизнь — она сложна .
ЗХ>Я же говорил только о том, что для "разумно простой системы" аргументы рода "а если у тебя 194 класса, без интеллисенса и проверок на этапе компиляции не обойтись" — могут быть неактуальны.
Ну вот скрипты и используют для простых задач типа несложных веб-сайтов, отсюда PHP один из самых популярных языков.
Но для того, чтобы это работало, нужна инфраструктура (веб-броузер; веб-сервер; софт, реализующий сетевые протоколы; СУБД; PHP-интерпретатор) и ее не напишешь на PHP.
АХ>P.S. Как я не раз говорил, знаем типы — работает интеллисенс и навигация по коду, и это реально упрощает и ускоряет процесс разработки очень нехило.
Наверно поэтому интеллисенс и навигация по коду в WingIDE (python) работает лучше чем в VS 2005 для C++ (и не хуже чем там же для C#)
Позволю себе задать несколько вопросов по некоторым совершенно странным пунктам в высказываниях VladD2, с которыми ты согласился:
VD>>Так же несомненно, что качественная статическая типизация в купе с типобезопасностью и грамотным компилятором позволяют контролировать огромную часть ошибок до запуска программы и тем самым повышают ее надежноть, делают возмоным проводить более длинные циклы "придумал/написал/запусти/отладил" нежели в динамических языках, АХ>+1
Что это за задачи, в которых огромная часть ошибок вылавливается еще до запуска программы, а упоминания об алгоритмических ошибках или недопонимания части граничных условий, или игнорирования ряда исключительных ситуаций нет вообще? Что это: разработка компиляторов, ядер OS, оптимизаторы планов выполнения запросов в RDBMS, системы АСУТП, системы поддержки электронных платежей, встроенные системы для бытовой техники, ...?
Если не сложно, то с примерами на пальцах для такого тупого валенка, как я. А?
VD>>что в свою очередь дает возможность решать более сложные и отвественные задачи. АХ>+1
Что понимается под ответственными задачами? Опять же хочется примеров.
Неужели Erlang в телекоммуникациях используется для совершенно безответственных задач? Или контроль производства полупроводников на Smalltalk-е -- ответственности, надо полагать, там нет. Как и в системе управления аэропортом Хитроу на Prolog-е. Или анализ финансовых документов на Ruby. Или использование Python-а в Google. Вообще сам факт наличия заказных проектов, выполняемых целиком на динамически-типизированных языках (вроде SmallTalk, Tcl, Python), не является показателем ответственности (хотя бы исполнителей перед заказчиками)?
Может быть ответственные -- это полеты в космос? Так ведь, сюрприз, сюрприз, shit happens
Здравствуйте, Андрей Хропов, Вы писали:
ЗХ>>Слабосвязность в некотором роде рулит всегда. Я имел в виду не только ее. Для примера: MS Outlook, если его использовать только как мэйлер, явно "чересчур большая и монолитная" система, которую хрен настроишь и которая падает время от времени из-за разных конфликтов между частями. При этом, сущностей-то там всего ничего АХ>Ну вот насчет того, что всего-ничего не соглашусь (см. также ниже).
АХ>Но с другой стороны вот Спольcки высказывал такое мнение (здесь):
[...]
АХ>И мне кажется что оно имеет под собой основания. А так как MS делает продукты для максимально широкой аудитории и требующие минимальной настройки, то проще нагрузить Outlook редко используемыми фичами, чем кто-то бы сказал, что "этой фичи нет".
Ну, тут дело такое... У каждого свой взгляд, и спорить на эту тему бессмысленно.
Мой — я недавно излагал вот тут
и дальше по ветке: мне "богатство фич" кажется приемлемым, только когда вытекает из внутренней целостности (небольшого количества основных концепций). А встраивать "все возможности, какие только могут хоть краем относиться" — считаю злом, как раз и приводящим к 80/20 (т.е. 80% людей используют 20% фич — для каждого этот набор разный, потому что для каждого следующего пользователя "естественны" только 20% фич продукта). Т.е. с моей точки зрения, "правильная" (в некоем высшем смысле, несколько оставляя в стороне маркетинг) программа — в первую очередь концептуально целостна. Крайне грубо говоря, не один Word с 2000 фич, а отдельная программа для писателей, бизнес-врайтеров, тех-врайтеров и, допустим, юристов.
АХ>Справедливости ради скажу, что у меня никаких проблем с его настройкой и падениями не было.
Углубляясь в детали: он как-то очень интенсивно работает с буфером обмена (дергает его каждый раз при активации своего окна), что вызывает непредсказуемые глюки в сочетании с другими следящими за буфером программами (например, постоянная совместна работа FlashGet и Outlook вызывает странный эффект — Outlook работает как раньше, но его меню не реагируют на мышь и клаву — причем все меню, и главное, и всплывающие).
ЗХ>>Я же говорил только о том, что для "разумно простой системы" аргументы рода "а если у тебя 194 класса, без интеллисенса и проверок на этапе компиляции не обойтись" — могут быть неактуальны.
АХ>Ну вот скрипты и используют для простых задач типа несложных веб-сайтов, отсюда PHP один из самых популярных языков. АХ>Но для того, чтобы это работало, нужна инфраструктура (веб-броузер; веб-сервер; софт, реализующий сетевые протоколы; СУБД; PHP-интерпретатор) и ее не напишешь на PHP.
Ну, помимо Personal Home Page есть еще "новые фреймворки" (рельсы для руби, Django для питона и т.п.), которые, оставаясь скриптами, делают всякие MVC, DSL и много других страшных слов. Впрочем, в эту тему лучше не скатываться — тут будет только флейм
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>P.S. Как я не раз говорил, знаем типы — работает интеллисенс и навигация по коду, и это реально упрощает и ускоряет процесс разработки очень нехило.
FR>Наверно поэтому интеллисенс и навигация по коду в WingIDE (python) работает лучше чем в VS 2005 для C++ (и не хуже чем там же для C#)
К сожалению сейчас трафик экономлю (скачать не могу), но интересно как это он так работает:
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, FR, Вы писали:
FR>>Здравствуйте, Андрей Хропов, Вы писали:
АХ>>>P.S. Как я не раз говорил, знаем типы — работает интеллисенс и навигация по коду, и это реально упрощает и ускоряет процесс разработки очень нехило.
FR>>Наверно поэтому интеллисенс и навигация по коду в WingIDE (python) работает лучше чем в VS 2005 для C++ (и не хуже чем там же для C#)
Да, в процессе изучения темы натолкнулся на товарищей пишущих интеграцию Ruby в VS2005
которая называется Ruby in Steel : здесь.
Там как раз кое-что есть про интеллисенс, в частности здесь.
Только непонятно разрулили ли они таки последний пример:
Здравствуйте, vdimas, Вы писали:
V>Это все так и есть, и за скрипты я не агитировал. Просто у меня есть мнение, что в среды разработки для того же C# можно включить некоторые способы, которые автоматом есть для динамических языков (Lisp, SmallTalk или даже нединамический, но очень интерактивный Fort).
Вряд ли кто-то будет против расширения функциональности. Так что я тоже "за". Но Лисп, Смолток и т.п. на сегодня сильно проигрывают Стуии и Идее во многих отношения. И если речь будет идти о замене одного на другое, то я лично предпочел бы возможности Стуии и Идеи, а не эти расширения.
V>Сам язык C# вкупе с дотнетом имеет такие характеристики, что написать скрипт-машинку для языка C# мне представляется вполне возможным.
Зачем? Процессоры на сегодня шустры. Инкрементальная компиляция тоже может быть шустрой если реализована грамотно. Так что скриптовость тут вовсе не нужна. Вот только компилятор C# имеет смысл переписать на C#-е же. А то загрузка отдельного процесса резко азмедляет процесс компиляции.
V>Для примера можно взять VB (не дотнетный, а тот, который последний 6.0). На этапе оладки конкретного проетка он представляет из себя скрипт-машину без ущерба для св-в типизации языка (которое было введено с 4-го VB), после отладки можно скомпиллировать двоичный модуль, получаем вполне оптимизированный двоичный результат.
Ага. Отличный пример. От этого и отакзались в VB.NET. И мне кажется что не зря. То что получили взамен сильно превосходит то что было. Практически все что было в ВБ 6 есть сейчас в VB.NET. При этом есть полноценный быстрый комилятор и много удобных фич. Нафига нам обратно в каменный век?
Господа, поймите. В МС ведь не идиоты работают. Они предпочли JIT-машину интерпретатру не с бухты барахты. Это серьезный выбор которому предшествовал нехилый анализ.
V>Мне думается, что пока что MS очень активно разрабатывает новые версии самого языка C#, и просто руки не доходят до разработки полного скриптового аналога текущего варианта.
Мне кажется, что тебе кажется. Возможно рантайм дотнета получит в будущем некие более динамичные вещи. Это размуно и не противоречит концепции. Но идти назад к скриптам — это не разумное решение.
V> К тому же многие программисты на C# — это скорее бывшие плюсовики/джава-программисты/дельфисты, т.е. люди, которым описанная фича ранее никогда и не нужна была.
Ыгы. А наши два доблесных скриптовика видимо пришли со Смолтока или Перла. Смешно, блин. 90% современных программистов до 1995 (если конечно они тогда программировали) года писала на С, Паскале или их вариациях (Турбо Паскаль, Дельфи, С++...). И те кто сегодя пишут на Питоне или Руби тоже.
В общем, я уже говорил. Не хочу спорить. Это мое ИМХО, в смысле Имею Мнение Хрен Оспоришь.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Я думаю что основным преимуществом скриптовых языков является рантайм duck typing или принцип АХ>EAFP (Easier to Ask Forgiveness than Permission). Т.е. полиморфизм без необходимости явно иметь интерфейсы.
Это заблуждение. Курим ML-подобные языки.
Динамическая типизация и утиная типизация это две совершенно перпендикулярные проблемы. Есть статически типизированные языки с дюктаймингом. И есть динамические с жесткими интерфейсами.
АХ>В то же время этот подход снижает надежность.
Откладывание выявления ошибки всегда приводит к менее надежному резулттату и усложнению отладки. От этого страдают даже шаблоны С++ хотя их в динамичности уж точно не "упрпекнешь".
VD>>Так что мой прогноз такой. Скрипты все больше и больше будут проигрывать.
АХ>Пока наблюдается обратная картина.
Где и кем? Впрочем, можешь не отвечать. Я высказал свое мнение и спорить не буду. Один хрен сейчас понабегут наши фанаты динамики и разведут очередной флуд. Мне это надоело.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, eao197, Вы писали:
E>Что это за задачи, в которых огромная часть ошибок вылавливается еще до запуска программы, ...
[булшит поскипн]
Любые задачи. Особенно большой бенефиг когда вносишь изменение в большое количество мест огромного проекта создающегося не одним человеком.
E>Если не сложно, то с примерами на пальцах для такого тупого валенка, как я. А?
Неплохими примерами являются Интеграция со студией и Компилятор Немерла над которыми я сейчас работаю (в свободное от работы время ).
Вот буквально недавно написал довольно распределенный по файлам двух проектов алгоритм инкрементальной компиляции методов. Компилятор матерился раз 10 (10 запуско, а не ошибок). Он мне не только на явняе опечатки, но и на ряд нехилой сложности логических ошибок связанных с неверной интерпретакцией переменных и т.п. В итоге код заработал после первого запуска вообще без отладки.
VD>>>что в свою очередь дает возможность решать более сложные и отвественные задачи. АХ>>+1
E>Что понимается под ответственными задачами? Опять же хочется примеров.
Ну, то есть по первому пункту (сложным задачам) прений не будет.
ОК, готов снять тезис об отвественности, так как средсва контроля конечно могут быть разными. Море тестов, тотальные проверки, наличие стратегии обработки ошибочных ситуаций и четкое продумывание задачи позволяют добиться устойчивости. Вопрос тольк в цене. Так что заменяем тезис на "решать отвественные задачи с меньшим количеством трудозатрат".
E>Или интеграция чего-нибудь в VS -- это и есть предел ответственности в софтверных проектах?
Не менее отвественная чем велосипеды вроде движка обмена сообщений или скрипта по сборке проектов. Особенно с точки зрения прогесса. Телекомуникация Эриксона никому кроме него и его акционеров не важна (о твоих велосипедах и речи не идет). А вот развите компьютерной науки вещь очень важная.
E>Или же стоит заглянуть в разделы Success Stories для того, чтобы расширить свой кругозор:
Это вопросы или очередной выпендреж перед своими поклонниками? Я уже сказал, спорить не сообираюсь. Так что не напрягайся.
E>И в завершение позволю себе еще раз процитировать
Да кто же тебе запретит то?
E>А ответы на свои вопросы я надеюсь получить.
Какие ответы? Ты ведь не вопросы сюда пришел задвать. Сознайся! Тебе ведь плевать на них и на чужое мнение. Ты ведь уже все для себя уяснил и решил в очередной раз покичиться перед гурппой поддкржки. Ну, а ответы то тебе при этом зачем?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Спецы по IP обычно являются фанатами IP, что снижает полезность обсуждения. 
есть еще "новые фреймворки" (рельсы для руби, Django для питона и т.п.), которые, оставаясь скриптами, делают всякие MVC, DSL и много других страшных слов. Впрочем, в эту тему лучше не скатываться — тут будет только флейм 
: здесь.
.
