1) Не правда. Перл производительности уровня питона, а на питоне оно не тормозит. Как пример посмотри SPE на wxPython: полноценная(!!) IDE. Не тормозит даже на древнейшем железе.
2) Не правда. Используйте wx/qt. У них дефолтный вненшний вид. Как пример, тот же SPE.
Прежде, чем что-то говорить, неплохо бы разобраться в теме хоть немного.
мда, весело, тема про гуй на пхп вызвала эпический холивор, с упреками о говноязыке пхп
ну а с перлом не, все ок, можно писать говногуи, по своим характеристикам сравнимые с технологиями конца 20 века
троллим
ну и чем он православней пэхэпэшечки-то? на них обоих можно писать gui, но разрабатывались ли они изначально под это? а костыли это «не православно» имхо
вообще есть всем известные С С++ Pascal, наконец VB и VB.NET
С — нет объектов, очень тяжело программировать :(
C++ — есть объекты, но дурацкий синтаксис, надо описать у каждого по 5 корнструкторов, нет параметров со значениями по умолчанию, надо писать хедеры, нет авт. управления памятью, нет встроенных высокоэффективных опреаций со строками или массивами. Синтаксис 20-летней давности, нет делегатов ну и много еще чего, хотя можно было бы и сделать! При работе возникает много утечек памяти и всяких access violations.
VB —вообще ужас имхо.
Есть, правда язык D, в нем почти все есть, но он вроде со сборщиком мусора (фууу :( ), и от шаблонов и строгой типизации там тоже не смогли избавиться.
На чем писать Гуи то?
p.s Питон и Руби само собой не катят, едят память как бешенные и не компилируются в ассемблер.
Я вот недавно тоже задался таким вопросом. Плюс у меня еще была в требованиях кроссплатформенность. Всё к чему удалось прийти — Java. К сожалению не нашел в себе моральных сил ее освоить. Знающие люди говорят, что сама по себе она несложна в освоении, для опытного программера. Но вот с фреймворками придется поразбираться…
Ох, Ява тяжеловата (это мягко говоря), и более того, любой ГУИ-фреймоврк на ней потянет за собой тонны кода… маленькую изящную программку там не напишешь.
но постойте, оно же графическое приложение, т.е. предполагается какой-то пользовательский графический интерфейс непосредственно для взаимодействия с пользователем, тогда с чего его начинать?
С проектирования архитектуры программы наверно, там компоненты отдельные, классы и прочее. Мне как веб-разраьотчику сразу всякие MVC в голову приходят.
А delete руками что ли писать? Ну будьте реалистом, в программе среднего или большого размера это просто невозможно, все силы разработчика будут уходить на поиск утечек памяти, да и неправильно как-то это, думать где освободить память, пусть железка думает а не я.
Я им сочувствую :) Если серьезно, считаю, что ошибки переполнения буфера, или утечки памяти — невозможное явление в 2009 году и, если они у кого-то есть, ему надо серьезно задуматься!
Речь идет не о выборе языка, а о выборе средства разработки интерфейса для перл-программиста. Сейчас языки типа перла, питона, руби предоставляют примерно одинаковые возможности, просто отношение ко многим вещам разное. Поэтому сейчас выбор языка это не выбор каких-то параметров, а подбор удобного ОПРЕДЕЛЕННОМУ программисту инструмента. Вообще, я надеюсь, что с появлением качественных компиляторов для всех более-менее популярных языков на Parrot, холиварщики призаткнутся.
> Поэтому сейчас выбор языка это не выбор каких-то параметров, а подбор удобного ОПРЕДЕЛЕННОМУ программисту инструмента.
В каких объективных терминах выражается удобство?
Вот допустим, есть вполне конкретная задача. Дана формочка, с которой мы хотим получить данные. Используя wxHaskell+wxGeneric, можно быстренько отобразить контролы формы на структуру данных (умненький компилятор сделает все сам, практически без нашего вмешательства). Если не пользоваться wxGeneric, тогда весь код перекидывания данных туда-сюда (между GUI и структурой данных) придется писать ручками, что чревато.
Что Перл может предоставить программисту в этой задаче?
> Вообще, я надеюсь, что с появлением качественных компиляторов для всех более-менее популярных языков на Parrot, холиварщики призаткнутся.
Причем тут холиварщики? Parrot будет к концу года вроде бы, а там уж и Unladen Swallow, и еще V8… Скоро наконец догонят древний Common Lisp.
> Вот допустим, есть вполне конкретная задача. Дана формочка, с которой мы хотим получить данные. Используя wxHaskell+wxGeneric, можно быстренько отобразить контролы формы на структуру данных (умненький компилятор сделает все сам, практически без нашего вмешательства). Если не пользоваться wxGeneric, тогда весь код перекидывания данных туда-сюда (между GUI и структурой данных) придется писать ручками, что чревато.
Виджеты Tk имеют свойство textvariable. Поэтому данные, которые вы вводите, будут храниться в переменных.
my $ok = 'OK';
my $button = $main_window->new_ttk__button( -textvariable => \$button );
1. ActiveState PPM, PDK написаны с использованием этой библиотеки.
2. Гарантированно (проверял везде) работает на Windows, Mac OS X, Linux, Solaris.
3. «Родное» оформление.
4. Мне необходимо использовать событийную машину (POE), поддержка Wx слабо реализована search.cpan.org/~mike/POE-Loop-Wx-0.04/lib/POE/Loop/Wx.pm
а в случае с Tkx, «мост» уже почти написан, скоро засабмичу в CPAN ;)
5. В бинарном файле места занимает в два раза меньше.
Слушайте, в Перле же если я не путаю, очень извратный синтаксис, так что ничего не понять? И я слышал там даже аргументы функциям как-то извратно передаются, через $@, а не скобки, а уж объекты там вообще непонятно как делать. Как на нем вообще можно писать что-то?
Синтаксис извратным кажется, когда Вы не знакомы с ним. Согласен.
Но по изучении, Вы поймете что ошибались.
На самом деле все просто. Аргументы передаются через вектор @_.
Приведу небольшой пример: необходимо написать подпрограмму(sum) которая суммирует два числа.
my $result = sum( 3, 4 ); # result = 7
варианты
sub sum {
my( $a, $b ) = @_; # распаковываем все сразу
return $a + $b;
}
sub sum {
my $a = $_[0];
my $b = $_[1];
return $a + $b;
}
sub sum {
my $a = shift @_;
my $b = shift @_;
}
так как shift без явного задания аргумента, извлекает первый элемент из _ то можно написать
sub sum {
my $a = shift;
my $b = shift;
return $a + $b;
}
можно и вообще return опустить
sub sum {
$_[0]+$_[1];
}
Хоть оно и будет работать, но так писать не следует. (хотя для perlgolf'ов сойдет :)
Нужно придерживаться стилю программирования.
«There's more than one way to do it» — Larry Wall.
А вот и другой пример: написать подпрограмму которая будет суммировать все переданные ей числа
my $result = sum( 1, 4, 6, 7 ); # 18
sub sum {
my $s = 0;
$s += $_ foreach( @_ ); # прибавляем к $s каждый элемент из @_
Вот-вот, вы только и подтвердили мою мысль, что Перл — изврат (ну или искусство :) по вашему ), во-первых, путаешься же, во-вторых, мне в свое время надоело писать эти my () = @_ в начале каждой функции. Куча двусмысленностей, типа контекста массива/литерала (или как оно назывется?) или операторы if *после* строки с кодом. Синтаксис мозг выносит напрочь! страшно представить себе большой файл с таким кодом.
чепуха, так можно о любом языке программирования сказать не особо вникая в суть
1. в Perl есть прототипы, для тех кто любит указывать тип передаваемых данных в функции (ну и не только для них =) )
2. мне в свое время надоело писать эти my () = @_ в начале каждой функции — чепуха,
во-первых это не обязательно писать
во-вторых менять список типов и названий аргументов у функций при рефакторинге, более утомительное занятие
ну и наконец:
вместо того чтобы повторять какие-то несуществующие мифы и придумывать несуществующие проблемы, проще попытался бы ознакомиться, что это за язык и «с чем его едят», для Perl самая замечательная (и очень занимательная!!! что достаточно непривычно в области изучения языков программирования) книга по программированию которую я когда либо читал в жизни — Программирование на Perl (3-е изд.) [Л. Уолл, Т. Кристиансен, Д. Орвант]
C GUI на перле я разбирался несколько лет назад и даже несколько программ написал для людей. Вывод — для реальной разработки он малопригоден, при манипулировании большим количеством данных торможение невероятное. Perl-Tk удобен для мастерения небольших формочек, но отсутствие вменяемых пакетов для построения этих формочек вынуждает всё делать руками. В результате быстрее выучить С# для Mono или Java, чем долбиться с перлом и в один прекраснй момент обнаружить, что в мультитредовом режиме принципиально работать он не хочет.
Cам наступал на те же грабли. Заставить работать Tk+threads можно, если потоки задавать ДО создания UI.
Правда там и в документации было написано что «Tk isn`t thread-safe»
Год-два назад мне не удалось этого сделать. Сам гуи запускался, но после того, как управление попадало в поток (т.е. после того, как на кнопку любую нажмешь) — все крашилось со страшными ругательствами. Потоки создавал и до, и после, и «посередине» :)
Буду благодарен, если осветите эту тему в статьях.
Наткнулся недавно в интернете на одну разработку, называется Win32::GUI:
Это инструментарий для работы с графическим интерфейсом Win32 из Perl. Представляет собой XS-реализацию большинства функций из user32.dll и gdi32.dll с объектно-ориентированным perl-интерфейсом и основанной на событиях моделью диалогов.
счастливые вы люди, если можете выбирать, на чём писать.
у нас в конторе все гуи исключительно на делфи, с радостью бы использовал перл, ничего устаревшего в нём нет. *nix вообще с 60-х годов, но устаревшим никто не называет :)
Perl и GUI. Сравнение тулкитов