Чего-то этот клуб не очень активен. Видимо, немногие участники форума интересуются программированием. Хотя сама тема программирования неоднократно проскакивала, примущественно в обсуждениях про работу.
В этой теме хотелось бы предложить рассмотреть не программирование как работу, а программирование как творческий процесс создания программ, сайтов.
Как проявляются ваши сильные функции при написании программ?
И обратный вопрос: можно ли по программному коду предположить ТИМ программиста?
У меня на работе есть замечательная возможность наблюдать, как ИМ сказывается на стиле и подходе к написанию программ.
Рассказываю
Черный сенсор пишет программы "в лоб". Если это Макс - то это все-таки очень хорошие программы, потому что все-таки БЛ на первом месте. А если Жук - то программы похуже, потому что на первом месте "В лоб" Пишут быстро, мощно, прорубая широкие просеки.
Белые интуиты (Робы) склонны выстраивать сложные конструкции для простой задачи. Паттерны на паттерне там, где можно все сделать проще. Впрочем, иногда это вполне неплохо и полезно оказывается по прошествии некоторого времени, когда требуется расширять функциональность. А иногда - явный овердизайн, перегруз конструкциями.
Бальзаки программируют очень прикольно. Как-то так иногда "левой пяткой через правое ухо". Ну можно же - так почему нет? Особенно, если это приведет к укорочению программы на пару строчек. Правда, иногда в результате получается что-то совершенно непонятное остальным.
Джек пишет не быстро, а очень быстро. И с максимальной пользой. Сверх-эффективно. Ну, с точки зрения Роба, не слишком "чисто".
Дон у нас изолировался от всех и пишет что-то такое, что может быть кому-то пригодится, а может ыть и нет. Что внутри - никто не видел Иногда выдает что-то полезное, чаще - что-то удивительное
Этиков, извините, среди программистов не видел
Экстравертов, тоже минимум, на самом деле.
В основном интровертные логики, это четкая статистика, в т.ч. и в профессиональных исследованиях подтверждаемая.
Интересно, а сами Бали через пару месяцев смогут вспомнить и понять свое собственное творение? Или будет из серии - легче заново переписать, чем тут что-то добавлять?
Школа и навыки программиста могут вполне заслонить ТИМные черты. А вот сами языки программирования, по-моему, соответствуют некоторым качествам некоторых ТИМов.
Например, Java кажется мне олицетворением жёсткой структурной логики "Максима" (статические типы, интерфейсы, и т.п.)
Lisp, пожалуй, соответствует полёту абстрактной фантазии "Дона", с ответвлением в виде "Робеспьеровского" языка Scheme.
C++ напоминает мне "Бальзака" (или "Джека") своей эффективностью, подчас в ущерб эстетике.
Я прошу прощения, что вмешиваюсь я 8 лет проработала программистом ) Потом, конечно, поняла, что не мое. Пожалуйста, расскажите подробней, как именно Вы типируете по исходному коду? По каким таким признакам? ))
Из языков программирования больше всего любила java (JSP, struts, servlets), Perl. =*.*=
Мне тоже интересно, как можно осуществить такое типирование. Сомневаюсь в эффективности этой процедуры: идиомы конкретного языка, решаемая задача и программистский класс могут заслонить ТИМ. Впрочем, шутки ради можно было бы попробовать организовать разбор кода. Мне кажется, имело бы смысл оговорить решаемую задачу и язык программирования, предложив кодирование нескольким людям с ярко проявленными ТИМами (без предварительного раскрытия ТИМов на форуме).
Конечно, согласен, что язык программирования - штука формальная, и поэтому в первую очередь код зависит от опыта и решаемой задачи; средства выразительности, так сказать, сильно ограничены
Мне тоже просто интересно, что можно предположить (и можно ли) по поводу ТИМа программистов, а так-то я не типирую. Но не знаю, вдруг где-то такое есть)
Если профессионалы трудно различаются (хотя все равно - любимые подходы наверняка свои, а нестандартный, творческий код точно несет отпечаток мышления программиста-создателя ), то можно рассмотреть начинающих - кто, как, на чем учится, кому какие языки, задачи даются легче, какие ошибки типичны не столько для всех новичков, сколько для определенной группы. Кто по памяти может воспроизвести алгоритм быстрой сортировки, а кто до конца его так и не прочувствовал?
О языке программирования - а если бы была свобода выбора, какому языку было бы отдано предпочтение и почему? Конечно, это зависит от задачи, но можно сформулировать вопрос и так: какой язык программирования Ваш любимый и за что Вы его любите? Luthien, вот чем Вам нравится java?
Я вот влюбился в перл за то, что на нем можно писать коротко, но ёмко. Маленькие однострочники позволяют быстро решать разные возникающие мимоходом служебные задачки вроде найти в логе интересную строчку. Плюс нравится возможность программный код приблизить к естественному английскому. На perl даже стихи пишут
Ага, можно Нужно только найти достаточное число участников.. но сначала интересную задачу, наверно, чтоб ее можно было запрограммировать на нескольких языках на выбор, и притом несколькими способами.
Пожалуй, eщё одна проблема с типированием по программам -- малая пригодность этого метода для типирования этиков.
Первый "взрослый" язык, освоенный мною -- это Perl. В нём меня (как и Вас) привлекла возможность кратко и без бюрократических перегрузок выразить свою мысль. Эта особенность была ключевым фактом в моём обучении -- очень быстро стали получаться полезные программы и появилось ощущение контроля над возможностями компьютера. В этом отношении Perl заметно контрастирует с языком Java, да и другими компилируемыми языками -- их освоение требует гораздо более продвинутой компьютерной культуры. (С другой сторны, при увеличении сложности проекта наступает момент, когда жёсткость и бюрократическая бескомпромиссность Java'ы начинают оправдывать себя.)
В последнее время часто пользуюсь языком JavaScript для небольших проектов и обучения студентов. JavaScript имеет многие положительные черты Perl'а (возможность быстрого старта, богатые выразительные способности) и дополняет их своей интегрированностью в браузеры, а также и современным синтаксисом. Браузерная платформа практически гарантирует вездесущность языка, устраняя необходимость его инсталляции. Кроме того, исполнение кода внутри браузера даёт пользователю дополнительную безопасность при использовании распространяемых на просторах интернета программ. (Именно чтобы не отпугивать потенциальных пользователей, я и использовал JavaScript для написания калькулятора Рейнина.) Студентов этот язык привлекает своей мгновенной применимостью для конструирования интерактивных веб-страниц и отсутствием нужды в его инсталляции. С другой стороны, платформа накладывает заметные ограничения в применении JavaScript'а для системных задач.
Ещё два языка которые мне нравятся -- это Scheme и SQL. Впрочем, SQL привлекает своей способностью выражать идеи реляционной алгебры и нормализации данных, а не своим архаичным синтаксисом. Sheme -- это определённая предельная точка в отношении стилистической чистоты языка, вкупе с несравнимыми ни с чем другим (вне семейства Lisp'а) возможностями к абстракции.
Наверное смогу предоставить программы двух своих друзей с ярко выраженными ТИМами. (Себя предлагать в качестве автора боюсь, так как не вполне уверен в своём собственном ТИМе, но тоже могу попробовать.)
А Джека как раз Perl и Java. Perl -потому что действительно хорош и перспективен (я бы поставила на него, а не на php), Java -потому что универсален и независим от архитектуры.
За ущербную эстетику -отдельное спасибо, конечно, но как раз к C++ это не очень относится. Да и потом C++ - он все-таки больше для системных программистов -и это, скорей, к тем, у кого БЛ в базовых функциях. Опять-таки - а что называть эстетикой в языке программирования?
Еще для научных программистов все еще актуален старый добрый Фортран -и почему-то среди Донов он популярнее всех по моим наблюдениям.
Скорей тогда уж типирование не по программам, а по предпочтениям.
Хотя, может есть какие-то тенденции -внутри кода -типа какая там организация циклов или какие используются названия переменных.
Хочу подчеркнуть, что при рассмотрении языков я говорю о своих субъективных ассоциациях, а не о предпочтениях известных мне представителей тех или иных ТИМов.
Ассемблер, конечно, эффективная вещь -- но это эффективность, начисто лишённая масштабности и глобальности, которыми как раз отличаются Бальзаки и Джеки.
Perl скорее бесперспективен. Конечно, его использование в качестве языка системного администрирования гарантирует ему долгую жизнь, но для масштабных проектов разрабатываемых большими коллективами он намного менее пригоден, чем Java. Его основное достоинство, на мой взгляд -- в его толерантности к другим средам и программам, обитающим по соседству. В силу этого свойства он идеален для написания скриптов, "склеивающих" воедино несколько программ написанных на разных языках. Php -- по сути дела вывернутых на изнанку Perl (где роль изнанки играет HTML), причём несколько кастрированный в процессе этого выворачивания. Поэтому я бы не стал отделять одно от другого -- по сути это один язык, просто на разных платформах.
А вот основное достоинство (или недостаток) языка Java -- в его способности жёстко устанавливать интерфейсы. Эта особенность сдерживает развитие малых и средних программ, но очень помогает при разработке больших продуктов коллективами независимых (или слабо зависимых) программистов. Поэтому Java и ассоциируется у меня с ТИМом Максим с его жёсткой структурностью и волевой сенсорикой.
Хмм.. Мне кажется налицо небольшое передёргивание: "в ущерб эстетике" и "ущербная эстетика" -- далеко не одно и то же.
C++ -- а то и просто C -- как раз и используются для системного программирования в силу своей быстроты и эффективности. А вот с эстетической точки зрения C++ всё-таки напоминает монстр Франкенштейна. Красивый и совершенный язык С дополнили новыми объектно-ориентированными наворотами, сделав из него синтаксический винегрет.
Популярность фортрана, с одной стороны -- результат лени и инерции мышления. Слишком много библиотек написаны на этом языке чтобы от них отказываться в одночасье. С другой стороны, сам язык Fortran претерпел довольно значительную эволюцию, развиваясь в направлении от Ассемблера к Lisp'у: "Successive versions have added support for processing of character-based data (FORTRAN 77), array programming, modular programming and object-based programming (Fortran 90 / 95), and object-oriented and generic programming (Fortran 2003)." Если Вам довелось программировать на фортране 77, думаю Вы согласитесь, что современный фортран -- по сути дела другой язык.
В начале своего творческого пути Фортран вполне соответствовал Дон-Кихоту, но сейчас превратился в консервативного чёрного логика, пытающегося любой ценой сохранить накопленное (но морально устаревшее) добро, наводя на него запоздалый марафет. Может это соответствует ТИМу Штирлиц?
Мне кажется, название переменных -- это тоже отражение стиля программирования, почти в той же степени как и логическая организация программы.
Справедливости ради отмечу, что представления и ассоциации о ТИМах у Вас тоже субъективное.
Ну для меня (в моем таком примитивном восприятии) ассемблер –это такая магия –такая вещь-в-себе, ну и я чисто интуитивно это свое ощущение сопоставила с Бальзаками, как с самым загадочным ТИМом (опять же по моим ощущениям).
Про масштабность и глобальность Джеков не соглашусь -я часто сталкиваюсь с Джеками-программистами, которые не пишут никогда универсальных программ для типовых задач, а под каждую задачу пишут одну свою программу.
Хотя на мой (хоть и Джековский) взгляд -проще унифицировать один раз программу так, чтоб использовать её для задач одного типа, чем каждый раз писать новый код.
Спасибо огромное за ликбез. Я давно хотела узнать мнение специалиста по этому поводу.
А вообще у нас тема разбивается уже на две части –одна связана с ТИМами и типированием, вторая – просто с обсуждением языков и сред программирования.
Думаю, что вторую имеет смысл обсуждать отдельно, у меня во всяком случае имеется пробел по этим вопросам, который бы я с радостью заполнила за чужой интеллектуальный счет.
Я не передергиваю, а действительно не понимаю –куда применять понятие эстетики в программировании. Ну если только к пользовательским интерфейсам.
А почему Вам не нравятся объектно-ориентированные навороты?
Ну а по-моему это вполне здравомысленно –использовать то, что уже сделано, а не изобретать велосипеды. Это не лень –это экономия энергии и времени. Я бы вообще не писала программ, а скачивала написанное другими -для меня этот процесс ужасен, труден и занимает большую часть времени -а для науки собственно остается мало.
Ну нынешний фортран, конечно, другой, но синтаксис-то прежний.
Ну нет, тут что-то иное, чем Штирлиц. У Штирлицов ЧИ активационная.
Помимо фортрана сейчас есть масса сред, где библиотеки богаче и проще в применении –ну Матлаб, например.
Я пользуюсь фортраном только в случае, если требуется воротить большие массивы данных –ну, к примеру, строить какие-то регрессионные модели и обучать их на огромном числе примеров. Просто фортран быстрее работает на таких задачах. Хотя я могу быть не в курсе –может Вы посоветуете использовать что-то другое?
Я тоже самое сказала вообще-то.ну неважно.
Вообще-то, когда мы говорим о программировании –о кодах и предпочтениях –различать бы еще цели этого программирования. Очень разные предназначения программ же и разные «специализации» программистов.
У меня Ассемблер ассоциируется скорее не с магией, а с жёсткой оснасткой -- физическим оборудованием а не программными продуктами. Может это Габен?
Я имел в виду не совсем это. Просто для известных мне чёрных логиков характерно интегральное видение ситуации. А вот для Максимов и Робеспьеров, наоборот, более характерно "зацикливание" на какой-то узкой области или задаче. Действительно, стремление к универсальности в указанном Вами смысле -- скорее бело-логическая черта.
Я не специалист, а любитель.
А почему, собственно, это нельзя рассматривать одновременно? Мы же не претендуем на какую-то серьёзность в нашем обсуждении?
Я совершенно не имел в виду пользовательские интерфейсы, говоря об эстетике программ. Тут я действительно не могу передать свои ощущения в полной мере, но хорошая программа читается как стихи. Если Вам нравится Perl, могу порекомендовать автора по имени Mark Jason Dominus -- у него много таких "поэм".
Я совершенно не против объектно-ориентированного подхода. Мой критицизм был направлен против синтаксиса С++, где объектно-ориентированная часть является искусственной присадкой к (функционально ориентированному) языку С, а не органической частью самого языка, как, например, в языках Java и Javascript. На мой взгляд, даже в любимом Вами Perl'е объекты введены намного более элегантно чем в C++, хотя тоже являются позднейшим добавлением.
В этом я вижу проявление .
Ну не совсем. Синтаксис значительно расширен, чтобы выразить новые возможности.
Мне кажется, Матлаб ориентирован на несколько другие задачи. Его сила в символьных манипуляциях и визуализации, а не в численных методах как таковых.
Вот-вот. Как раз для этого Фортран идеально приспособлен. Первоначально Фортран был практически переводом ассемблера на более человеческий язык и по-прежнему остаётся достаточно близким к инструкциям процессора. Именно за счёт своей близости к аппаратному уровню он так эффективен при обработке больших объёмов вычислений.
Преимущество использования языков "более высокого" уровня не в быстродействии программ, а в быстродействии программиста.
Ну, это с какой стороны подходить к вопросу о масштабности, ассемблер позволяет не только писать программы для работы с железом, но также и самомодифицирующийся код в системах защиты, а также код, способный эти самые системы ломать вот это и есть очень тонко и глобально , подобные вещи (в смысле самомодификации программы) можно только на лиспе или scheme делать, но эти языки уже другой разговор.
Perl Vs Java? Мясо Vs Картошка?
Язык для системного администрирования, отчётов, как правило интерпритируемый, с "грязным" синтаксисом (вот тут бить не надо, потому что perl это так называемый "птичий язык") сравнивать с чистым ООП языком общего назначения не совсем корректно, несравнимые вещи.
Php это совершенно другой язык, явно не perl, хотя бы концепции их сравните. А что касается связи Php и HTML, то сейчас, её уже почти нет. Php превратился в универсальный скриптовый язык, чаще всего применяемый для разработки web сайтов, но и уже используемый для системных нужд администрирования.
Про фортран ничего сказать особо не могу... инженерный язык, скорость расчётов на котором превышает обычно скорость работы программ на СC++. Тоже вроде как нужный, именно из-за этого. Не на ассемблере же по конвейерам команды распихивать... А что касается скорости программиста... так не игрушки же на нём пишут, и не бух. программы.
Разность тимов, скорее в алгоритмах проявляется, в потоках управления данными, вот так даже точнее будет. По идее нужно посадить несколько тимов за комп и дать им по одинаковому заданию, а потом сравнить) хотя тут опыт тоже сыграет не последнюю роль.
Всё это так. Однако при написании программ на Ассемблере слишком много энергии программиста тратится на технические детали, что сдерживает концептуальный полёт мысли. Действительно, ассемблер позволяет вирусам влезать в самые узкие щели в системе (на стыке аппаратных средств и программного обеспечения), но самые интересные из известных мне вирусов написаны на лиспе -- именно потому что в нём способность к само-модификации сочетается со способностью к абстракции.
Почему нет? Вроде бы мы тем и занимаемся, что сравниваем разные языки. Кстати, ООП в Перле реализовано совсем неплохо, на мой взгляд намного лучше, чем в С++.
Конечно Php дальше от Perl'а чем, скажем, jsp от Java, однако это примерно тот же тип взаимоотношений.
Не могли бы Вы рассказать побольше о таких применениях Php, где он не используется для генерации веб страниц или обслуживающих этот процесс функций? Честно говоря я сомневаюсь, что Php имеет много применений вне серверов, тем более для системного администрирования. Для системных нужд лучше Perl или Bash shell.
Я отметил эту эффективность фортрана для больших объёмов сравнительно простых вычислений, когда писал про его близость к аппаратному уровню.
Ну так когда начинать будем? Какую задачу стоит вынести на конкурс?
Хм... не вижу смысла на ассемблере что-то мегабольшое писать, эту даже возможность не рассматриваю. Язык для работы с системным оборудованием, не больше + защита и прочее, как уже сказал.
Ну я выше писал, вещи не сравнимые, точнее очень ограниченно сравнимые. Standalone серверов не написать на perl, хоть там и ООП есть. Это как Php и C# сравнивать. Разный синтаксис, разные задачи, разная ориентация языков.
Например, возьмём perl и java. Задача такая: Получить текстовый фаил через web, распарсить его регулярным выражением, и результат сложить. Тут вся мощь перл проявится как нельзя лучше, java это же решит в 2-3 раза дольше. Отлично, начинаем делать сайт компании, с прайсом и магазином - теперь вся мощь perl - это большая беда, код расползается, плохо читается и прочее, а java работает. А теперь другая задача - нужен биржевой сервер, с базой данных, безопасностью соединений и прочим.... увы, перл этого не может. Как я уже говорил, разные задачи. Велосипед и джип. На одном быстрее до соседа доехать, на другом комфортнее до соседнего села добраться. хотя оба едут . С таким же успехом java и perl сравниваются.
Ну да, что php что perl скриптовые языки... этим они похожи.
Ну почему, вне серверов, как раз серверное применение он и имеет. Большая библиотека функций и плагинов, доступ к БД, сокетам, мощные языковые средства, стабильный и шустрый интерпритатор. Применялся в интеркере, для резервного копирования MSSQL, генерации отчётов и рассылки писем, для всяких заливок фаилов на фтп филиалов и прочего (в Windows 2003 Server), применяется в ЗАО Фармсервисе, там чото тоже такое творит, админ знакомый хвастался, что ещё и с пользователями работает, какие-то настройки им делает. Знаю фирму в мск, где он применяется для формирования отчётов на основе БД. У меня php стоит на компе (ОС Vista x64), пользуюсь, чтобы операции с фаилами какие-нибудь автоматизировать, в разы удобнее батников. В общем нетрадиционное его использование растёт))))). Универсальный скриптовый язык оказался.
Сравнительно простых?) проведение всяких головоломных операций с матрицами это просто? Особенно при моделировании процессов в газообразных средах, жидкостях, расчёте аэродинамики самолёта и прочее... Даже интелловский оптимизирующий компилятор СC++, до фортрана тут не дотягивает.
Насчёт задачи подумать надо. Может калькулятор простенький? Вещественные числа, скобки, унарный минус, функции и переменные. На вход строка, выход - число. Как раз за выходные можно Тока куда это добро выкладывать? Ну да, и у меня он наверное не получится, потому что буду делать стандартным классическим алгоритмом) это ничего о тиме не скажет)
Сервер можно написать на любом языке, который 1) полон в смысле Тьюринга и 2) поддерживает аппаратные возможности, необходимые для подключения к интернету, а именно может подключиться к сокету. Perl, безусловно, обладает обоими качествами, поэтому написать сервер на нём не только можно -- это даже уже сделано (поищите в Гугле "simple perl server").
Потому мы их и сравниваем, что они -- разные языки.
Не факт. Java практически полностью слизала синтаксис регулярных выражений из Perl'а (который, в свою очередь, взял их из стандарта POSIX), поэтому выразительные способности языков в области регулярных выражений одинаковы.
Программу на Perl можно быстрее написать (при прочих равных), потому что не нужно тратить столько времени на бюрократию. А вот функциональность вполне может быть примерно одинаковой. Возможно, отдельный прогон программы и окажется быстрее в языке Perl -- за счёт прекомпиляции и относительно длительной работы загрузчика классов в Java. Однако для работы с web Perl использует CGI, который гораздо менее эффективен в работе со многими одновременными подключениями, чем современные сервлет-контейнеры.
Perl всё это может. Я подозреваю, что этот сайт -- одно из доказательств этого постулата. Кроме того, один из моих друзей проработал несколько лет в инвестиционной компании на Wall Street в качестве программиста на языке Perl. Он как раз и работал над биржевым сервером.
Вопрос тут не в том, какой язык что может. Любой подключенный к аппаратным средствам полный по Тюрингу язык может выразить всё, на что способен любой другой язык -- языки с такими свойствами эквиваленты по своей формальной мощи. Дело тут скорее в их пригодности для выражения человеческих мыслей в доступной для компьютера форме.
Perl требует гораздо большей самодисциплины от программиста, поскольку даёт больше возможностей для самовыражения (в том числе и в совершении ошибок) чем Java.
Что такое "интеркер" я не знаю, а остальное так или иначе связано с ролью Php в качестве языка написания серверных приложений.
Тут ничего не могу сказать -- может они что-то там и делают за рамками серверных приложений.
Это способность -- необходимая часть современного серверного скрипта.
Мне кажется, это -- вопрос субъективного удобства, а не пригодности языка как такового. Вполне возможно, что привыкнув к Php в одном контексте, Вы считаете его самым удобным для решения всех подручных задач. В каком-то смысле он действительно универсален (он ведь тоже полон по Тьюрингу и имеет доступ к аппаратным возможностям).
Мне это напоминает один мой эксперимент по написанию скрипта для создания вэб сайта. Я использовал Javascript, но вовсе не потому, что этот язык очень пригоден для этой цели... Просто Javascript привычен для меня и у меня уже был вариант этого сайта в виде динамических вэб страниц на Javascript. Поэтому, когда мне понадобилось их переделать в статические страницы, я решил воспользоваться уже существующим кодом на Javascript и ActiveX.
В принципе да. Обычно проблема в матричных операциях -- в больших объёмах вычислений, а не в концептуальной сложности алгоритма.
Эти задачи не так просты, но опираются на уже существующие огромные фортрановые библиотеки для разностных схем и метода конечных элементов. За счёт использования этих библиотек, т.е. результатов работы предыдущих поколений программистов, может оказаться быстрее написать недостающие части на Фортране, тогда как написание всего приложения "с нуля" было бы значительно быстрее на C или C++.
Кстати, показательно, что программы для проекта по изучению генома пишут в основном на Perl, а не на фортране, хотя и там объёмы вычислений просто огромны. Это как раз пример вычислительной отрасли, развиваемой "с нуля".
Не знаю, не сравнивал. Скорее всего фортран действительно быстрее -- там код ближе к ассемблеру, чем в C++.
Вы имеете в виду стековый калькулятор (на основе обратной польской записи) или обычный инфиксный? Я давно собирался написать RPN-калькулятор. За выходные я не справлюсь -- у меня уйдёт гораздо больше времени на то, чтобы написать программу самому и склонить друзей-программистов к решению такой (довольно объёмной) задачи.
Да, на этом форуме со внешними ссылками -- беда. В принципе можно выложить прямо тут не очень длинный кусок кода.
Может и пришли, для меня системы защиты и вирусы это маштабные вещи, маштабность не всегда определяется объёмом кода
Я уже привёл аналогию для их сравнения. Оно само по себе не несёт смысла, так как призвано решать слишком уж разные задачи. Про регулярные выражения я ничего не говорил, они сейчас очень мощны во всех языках). Про то, что сайт сделать нельзя я не писал, просто время, для того, чтобы тоже самое сделать на java существенно меньше, как и количество ошибок будет мало по сравнению с perl (что этот сайт и подтверждает - просто огромное кол-во ошибок при разработке сайта на perl ) Такс, теперь про время))). Не будем сравнивать время работы интерпритатора и JIT компилятора java, потому что JIT всегда быстрее будет, после первого прогона ессно. Я имел ввиду время, которое тратится на разработку. При написание мелочей, на java мы будем дольше работать, но как только сложность проекта увеличивается, на java время разработки будет сокращается по сравнению с perl. Что касается CGI, то есть такая вещь, как FastCGI, оно как раз достаточно шустрое, в плане обработки web запросов, так что оно не критично. А какие задачи ваш друг выполнял, если не секрет, в этом биржевом сервере? Не думаю, что перл позволяет "самовыражаться лучше", он просто позволяет записывать сложные операции много короче.
У нас был один из проектов - сделать сервер для валютных спекулянтов, форекс короче, заказ из германии. Количество подключений около 8000-10000 тысяч единовременно, ну и плюс запасик, ос - windows 2003 сервер. В качестве языка выбрали C#, из за возможности легко обращатся к вин-апи и сборщика мусора. Ни один скриптовый язык тут бы в принципе не подошёл, и не только потому что его производительности не хватило бы, а ещё из-за того, что при таких маштабах подключений, будут работать только сокеты на порте завершения (CreateIoCompletionPort). Для любого скриптового языка эта проблема решается только через костыли. Хотя в других unix машинах (не windows) с сокетами много проще должно быть, но я с ними не работал.
Да эксперимет, уже собственно кончился, уже всё и вовсю работает). Я на php много не работаю, для меня он просто прикладной инструмент, у меня специализация CC++c#prolog. Там написано, что _применялся_ в интеркере, потому что это компания закрылась уже кажись... было 24 филиала по всей россии, торговала лекарствами. А удобство в данном случае, разве не означает пригодность? Объясните, какими качествами php не пригоден для такого?
мм... я уже говорил, что не совсем в этом дело, тут ещё и компилятор фортрана свою роль играет. В понедельник человека, кто занимался этим много лет, попрошу, чтобы отписался тут по этой теме.
Не корректно пример такой приводить, потому что подавляющие большинство исследовательские программы пишутся именно на скриптовых языках - по одной причине - чтобы их можно было легко модифицировать и запустить заново, потому что программа исследовательская, неизвестно что потребует - точнее известно - модификации кода, причём неизвестно как). Им же не нужен богатый GUI, и не нужна сверхпроизводительность и прочее. Lua например именно из-за такой исследовательской программы был создан.
А любой) Пусть кто как хочет, или как умеет, так и сделает. А выложим лучше всего в другой теме, а то куски холивара будут перкрываться исходниками . нехорошо будет))))
Да, я имел в виду масштабность в другом смысле (в смысле объёма решаемых задач и кода, а не в смысле важности для системы).
Приходилось ли Вам иметь дело с регулярными выражениями в SQL? Мне кажется что в самом языке SQL (а не специфических системах баз данных) поддержка RegExp сильно хромает по сравнению с современными языками (Perl, Java, Javascript, ...)
С этим-то я как раз согласен. Остаётся лишь процитировать самого себя (не смущайтесь, это я, просто у меня на этом форуме такое раздвоение личности):
А что это за компилятор? Это он компилирует в коды процессора, а не байт-код виртуальной машины?
В таком виде я не пробовал программы на Java, а когда Java используется внутри виртуальной машины, она обычно медленнее такой же программы на Perl (по моему субъективному впечатлению -- я не проводил настоящих тестов на быстродействие).
Опять же согласен -- см. выше.
Не знал про FastCGI -- уже давно не экспериментировал с Perl в серверных приложениях.
Не знаю (и не узнаю) деталей, но его работа была связана с анализом больших объёмов статистических данных и построении прогнозов на основе этого анализа. Данные собирались в том числе и с других веб сайтов (в чём особенно пригодился Perl) и выводились на защищённый паролем сайт компании.
Это я и имею в виду, говоря "самовыражаться лучше".
Вроде бы это как раз подтверждает мою мысль о том, что в Java (вариантом которой является C#) лучше организована работа с множественными подключениями. Подозреваю что C# может добиться дополнительной оптимизации за счёт использования системных возможностей, недоступных нормальной Java (за счёт использования тех самых Windows API, которые Вы упомянули в своём сообщении.)
Насколько я знаю, сборщики мусора есть во всех обсуждавшихся языках, кроме C и C++.
Как я уже говорил, удобство -- отчасти субъективная категория. Формально все полные по Тьюрингу языки, имеющие доступ к аппаратному уровню, пригодны для "такого".
В нормальной системе скрипт командной строки -- самый естественный инструмент для решения системных задач. Если выразительных возможностей командной строки не хватает, ближе всего к командной стоке, пожалуй, Perl -- он как раз и создавался на основе Unix shell. Поэтому Perl, в отличие от Java, так толерантен к наличию других программ и языков. Он идеально подходит для "склейки" разнородных ресурсов воедино.
Отлично.
О том и речь: фортран используется в определённых областях не потому что он -- самый выразительный язык, а потому что он быстр и имеет большие и проработанные библиотеки приложений в этих самых областях.
Производительность в работе с геномом тоже ой как нужна.
Вообще-то такие исходники больше соответствуют теме этой ветки. Может всё-таки выкладывать здесь?
Маштабный объём задачи... ну вирус морриса, положивший всю америку)))
Дык в чистом SQL нет кажется регулярных выражений, если 'like %...%' не считать), эта функциональность вынесена в специфические расширения СУБД. Я работал только с диалектом Firebird 2.1 - FSQL, там достаточно мощные регулярники включили в поддержку именно с 2.1 версии, с T-SQL для MSSQL сервера, да собственно и всё. как в PostgreSQL я незнаю, в Oracle тоже, хотя я там писал, но таких задач не стояло.
да, именно он компилирует коды для виртуальной машины в процессорные инструкции. У java же есть JVM (Java virtual machine) и JIT (Just In Time [compiler]), и всё это богатство входит в JRE. Начиная с версии Java 2. На сайте sun в поиске достаточно вбить JIT, он кучу ссылок выдаст по этой теме. Я бы тут привёл пару ссылок, но это будет считаться рекламой корпорации.. хехе), как будто такой корпорации нужна реклама здесь...
Да принцип такой же, как и у CGI и ISAPI одновременно. Запросы идут как для CGI, только программа остаётся в памяти, после выполнения запроса, и время на её загрузкувыгрузку не тратится.
Ну я про это и говорил, анализ, отчёты, вот что perl делает очень эффективно.
C# вариант Java? Даже не знаю, язык с Си подобным синтаксисом, скорее уж дядя двоюродный), все они варианты С - С++, Java, C# ну и там чото ещё, одни близки к C, другие не особо.
Да, сборщики мусора есть везде, кроме как С/С++. У C# и код, который JIT генерирует будет побыстрее java'вского. Сравнивали различные алгоритмы в работе, на Framework 2.0, так там производительность кода на C# была сравнимой с Delphi 6-7. А последнее это уже нативная среда для windows....
Какие критерии "нормальности" системы можно привести? Хм.. ну скриптовые языки всегда толерантны ко всему, такая уж у них работа)
Ну дык, perl, это же не JavaScript для браузера, побыстрее должен работать), не думаю, что у него низкая производительность. Было бы настолько всё настолько критично к производительности, переписали бы на фортране или сях. Тем более, когда багаж кода большой есть, работает с приемлемой скоростью, зачем переписывать и пытаться ещё ускорить то, что отлично работает? Да и вычесления я думаю, не на обычных системниках проводят с Core 2 Duо каким-нибудь, и 2Gb оперативки. м?
Вас ждали
Расчёт пути протонов в ваккуме будем делать?
Какие задачи есть?
.
вот это и есть очень тонко и глобально 
Какую задачу стоит вынести на конкурс? 
. нехорошо будет))))
