The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Скриптовые языки открыли новую эру в программировании

23.06.2008 17:18

"Scripting languages spark new programming era" - скриптовые языки открыли новую эру в программировании. В статье рассказывается об успехах JavaScript, PHP, Perl, Python и Ruby. Даже для платформы .Net появилась реализация языков Ruby и Python.

  1. Главная ссылка к новости (http://www.infoworld.com/artic...)
Лицензия: CC-BY
Тип: английский / Обобщение
Короткая ссылка: https://opennet.ru/16612-script
Ключевые слова: script
Поддержать дальнейшую публикацию новостей на OpenNET.


Обсуждение (38) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 17:30, 23/06/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно рассказывается? xD
     
     
  • 2.2, PavelR (??), 18:00, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Надеюсь, о дырявости реализаций скриптовых языков на различных платформах там также честно
    >рассказывается? xD

    Нет нет, что Вы, не рассказано. Расскажите, интересно послушать.

     
     
  • 3.3, Алекс (??), 19:00, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
     
     
  • 4.4, pavlinux (ok), 19:11, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать как надо.
     
     
  • 5.18, Кирилл (??), 11:31, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Пока железяки проектируют люди, будут нужны люди которые будут заставлять их работать
    >как надо.

    Это как же? Как надо? ))))
    Си сейчас постепенно занимает подабающее ему место в системном программировании. А уж ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более свежих языках. Ну ведь так это.

     
     
  • 6.31, User294 (ok), 16:15, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ошибки быдлокодеров на нём куда фатальнее для безопасности, чем на более
    >свежих языках. Ну ведь так это.

    Ну да, в итоге быдлокодеры наляпают на "безопасном" языке скажем биллинг.Ну, конечно код на нем не выполнишь напрямую.Зато транзакции могут быть реализованы абы как, логика работы может быть brain damaged и в итоге юзеры которых это должно биллинговать могут скажем шутя и совершенно легитимными и штатными действиями прокинуть обладателя этого гуано на такую сумму баблосов что лучше бы пожалуй там выполнили код.Это достаточно заметно хотя-бы и легко ловится.А вот логические ошибки и проблемы секурити обычно замечают только когда вас уже смачно натянули на много денег.

     
  • 4.5, Аноним (-), 19:42, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >ИМХО, популяризация "удобных" ЯВУ сделает сишников такой же сектой как сейчас ассемблерщики...
    >

    Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby ? В этом списке таких нет. JS примитивен и нет своих библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для небольших скриптов и без модулей вообще фигня уровня bash. Python - угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.

    Rexx в списке нет.

     
     
  • 5.6, kroz (?), 21:50, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>
    >
    >Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
    >? В этом списке таких нет. JS примитивен и нет своих
    >библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
    >небольших скриптов и без модулей вообще фигня уровня bash. Python -
    >угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
    >
    >
    >Rexx в списке нет.

    +100

     
  • 5.7, Anatolik (?), 22:54, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>
    >
    >Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
    >? В этом списке таких нет. JS примитивен и нет своих
    >библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
    >небольших скриптов и без модулей вообще фигня уровня bash. Python -
    >угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
    >
    >
    >Rexx в списке нет.

    Perl и Python ты осилить не смог -> Ruby можешь не смотреть.

     
     
  • 6.9, Anonymous (?), 02:18, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby
    >>? В этом списке таких нет. JS примитивен и нет своих
    >>библиотек. PHP - для "быстробучаемых веб-кодеров". PERL - стенографические иероглифы для
    >>небольших скриптов и без модулей вообще фигня уровня bash. Python -
    >>угрёбище, наплевавшее на всё кроме быстроты писанины. Ruby пока не пробывал.
    >>
    >>
    >>Rexx в списке нет.
    >
    >Perl и Python ты осилить не смог -> Ruby можешь не смотреть.

    PERL - мазохизм не для здоровых людей - язык для обработки текстов, созвездие кракозябр.
    Python - попсовая игрушка, гадящая сама под себя. Для быстрых набросков, которые потом нужно переписывать на чем то другом, чтоб не страшно было.

    Ruby посмотрю, но кажысь такое же детское безпринципное.

     
     
  • 7.17, prapor (??), 11:27, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Не освоив правило "жи-ши" глупо пытаться доказать свои знания "как правильно создавать языки программирования".
     
  • 5.8, lad (?), 23:32, 23/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Это какой из них по-вашему удобный? JavaScript, PHP, Perl, Python и Ruby

    Чем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в частности Zend), поддержка разных баз данных и еще много разных вкусностей.

    >PHP - для "быстробучаемых веб-кодеров"

    Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java и Rexx - всё зависит от того кто пишит.

     
     
  • 6.10, Anonymous (?), 02:22, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >
    >Чем PHP не удобен? Классы, виртуальные методы и свойства, отличные фреймворки (в
    >частности Zend), поддержка разных баз данных и еще много разных вкусностей.
    >
    >
    >>PHP - для "быстробучаемых веб-кодеров"
    >
    >Быстрое обучение это не минус. На PHP МОЖНО писать качественный код. Не
    >качественный код можно писать на ЛЮБОМ языке, включая C, C++, Java
    >и Rexx - всё зависит от того кто пишит.

    Можно и руками копать, но лучше лопатой. Просто средства разработки могут и должны способствовать писать легко и качественно. Это закладывается в язык разработчиками через концепцию и идеологию. Если в голове разработчиков языка бардак, то и писать на таком будет можно либо бардак, либо с большим напряжением для компенсации.

     
     
  • 7.14, lad (?), 10:07, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Можно и руками копать, но лучше лопатой. Просто средства разработки могут и
    >должны способствовать писать легко и качественно. Это закладывается в язык разработчиками
    >через концепцию и идеологию.

    Попробуйте Zend Framework. По Вашей аналогии - это экскаватор :-) Результат - чистый и понятный код, разделение данных и логики и т.д. Надо IDE - попробуйте Zend Studio.

    >Если в голове разработчиков языка бардак, то
    >и писать на таком будет можно либо бардак, либо с большим
    >напряжением для компенсации.

    Это применимо к любым языкам.


     
  • 6.11, Аноним (1), 02:41, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Ну многие при приёме на работу не пишут, что требуется php, а пишут asp или .net. Это для того, чтобы отсечь многих ламеров, начитавшихся "php для чайников". Хотя на самом деле, когда мне потребовалось написать код для сайта на js+php, подобные книжки меня не сильно порадовали. Слишком много тонкостей у этих языков, на деле всё оказалось сложнее чем в си. JS вообще беспредел, не понимаю, почему он получил такое распространение.
     

  • 1.12, Zoo (??), 08:23, 24/06/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Столько шума и ни одного аргумента! Ни одной ссылки!
    Пора прекратить это :-) Вот дл яразгона:
    Python vs Perl (с точки зрения программиста)
    http://michurin.com.ru/python-vs-perl.shtml
    Python vs Perl (с исторической точки зрения)
    http://michurin.com.ru/python-vs-perl-2.shtml
    PHP vs Perl
    http://michurin.com.ru/php-vs-perl.shtml
     
     
  • 2.13, SKeeper (?), 09:52, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
    Он пишет, что в php много модулей и это плохо, а вот то, что в perl можно подключить модуль и получить нужный функционал - это уже хорошо!
    Переносимость, как ее описывает автор, вообще сомнительное преимущество перла. Вот фактическая несовместимость PHP5 и PHP4 - это похуже будет.
    Так же автор говорит, что большое количество функций - это беда... уменьшает читабельность кода видети ли... Ну, во-первых, менее читабельного кода чем на перле я не видел (эзотерические языки не в счет). А, во-вторых, жизнь показывает, что лучше разобраться с готовыми функциями, чем писать свои. (из-за чего популярен стал мелкософтовский .net? потому что большая библиотека)
    Автор указывает perl-скороговорку как плюс перла, но плюс сомнительный. Иногда лучше удленить код в пользу читабельности.
    Дальше идут вполне обоснованные упреки в сторону пробелов в безопасности (вывод на страницу ошибок и т.п.), смещения HTML и кода... Но все эти упреки скорее к стилю программирования нежели к языку, в зрелом проекте данных ошибок не будет.
    Автор говорит, что неясно как передаются аргументы: по значению или по ссылке - вот это действительно минус, но минус, который еще надо умудриться встретить, но и он обходится использованием правильно документированных функций.
     
     
  • 3.15, Zoo (??), 10:07, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >статья "PHP vs Perl" просто лажа. "Аффтар" противоречит сам себе в ней.
    >
    >Он пишет, что в php много модулей и это плохо, а вот
    >то, что в perl можно подключить модуль и получить нужный функционал
    >- это уже хорошо!

    он говорит, что в PHP много **функций** (а не модулей), и от этого имена функций оченьдлинные.

    ну а вообще... вы зря упрекаете автора в любви к перлу :-) почитайте его заметки про питон, уж там-то он перл прописочивает :-) вам должно понравиться :-)))

     
     
  • 4.19, SKeeper (?), 11:33, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >он говорит, что в PHP много **функций** (а не модулей), и от
    >этого имена функций оченьдлинные.

    И про модули он тоже говорит, что из-за большого количества модулей надо искать хостера с нужным набором модулей.

    >ну а вообще... вы зря упрекаете автора в любви к перлу :-)
    >почитайте его заметки про питон, уж там-то он перл прописочивает :-)
    >вам должно понравиться :-)))

    Да я про статью восновном, а не про автора. Ну может я черезчур эмоционален, просто в последнее время, достали неаргументированные перлисты.

     
     
  • 5.20, Zoo (??), 11:56, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    И всё же я не понимаю. Вы про раздел "Количество функций"? Там говорится, что от хостера зависит не количество модулей, а количество функций.

    Вы, если не согласны и уверены в своей правоте, то напишите автору и поспорьте с ним ,-)

    А статья аргументирвоанная, с примерами...

    А главное вывод: все средства хороши к месту.

     

  • 1.16, lad (?), 10:36, 24/06/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У Perl две проблемы:
    1. Write-Only (не читабельный) код
    2. Отсутствует нормальная поддержка объектов

    Плюсы:
    1. Присутствует "из коробки" в любом Линуксе
    2. Модули на все случаи жизни

    Настоящая дилемма - и плюсы и минусы очень весомы.

     
     
  • 2.21, squirL (ok), 12:19, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >У Perl две проблемы:
    >1. Write-Only (не читабельный) код

    это проблема программистов, язык ДАЕТ возможность писать нечитабельно, но никто не мешает писать читабельно ;)


     
     
  • 3.22, Zoo (??), 12:32, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    А зачем он ДАЁТ? ,-)

    Кроме того, Perl часто провоцирует нечитабельность:
    - требование (пуcть и не жёсткое) распихивать каждый класс в отдельный файл
    - поощрение использования regexp-ов там где нужно и там где не нужно
      пример:
      Perlовик напишет if ($a=~/text/)
      Питонщик напишет if 'text' in a
      Что понятней? Я молчу о производительности.
    - можно продолжать... но суть в том, что Perl специально подталкивает писать непонятно.

    Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример исключений

    Логика программы становится менее понятна из-за "автооживления" переменных.

    Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else, есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли понять код, в котором такое используется?

     
     
  • 4.24, Sarge (??), 13:29, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    > Perlовик напишет if ($a=~/text/)
    > Питонщик напишет if 'text' in a
    > Что понятней?

    мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое "а" - то ли массив, то ли объект. А о том, что это скалярная переменная думается в самую последнюю очередь.

     
     
  • 5.27, Zoo (??), 15:22, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    а это и не обязательно скалярная переменна :-) в этом и есть преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и не только in) и большинство встроеных объектов его поддерживают. Угадайте, что такое in для массива? для словаря? получается? не прада ли удобно, когда язык объектно-ориентированный? ,-)
     
     
  • 6.29, JIP (??), 15:52, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >не прада ли удобно,
    >когда язык объектно-ориентированный? ,-)

    Perl вполне ОО язык имеющий встроенный механизм инкапсуляции :)
    стоит отличать pure языки от остальных

    зы конечно удобно :)


     
  • 6.36, Аноним (1), 10:06, 25/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >а это и не обязательно скалярная переменна :-) в этом и есть
    >преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
    >не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
    >такое in для массива? для словаря? получается? не прада ли удобно,
    >когда язык объектно-ориентированный? ,-)

    ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же

     
     
  • 7.37, Zoo (??), 12:06, 25/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>а это и не обязательно скалярная переменна :-) в этом и есть
    >>преимущество ОО (именно _НОРМАЛЬНОго_) -- любой объект может поддерживать in (и
    >>не только in) и большинство встроеных объектов его поддерживают. Угадайте, что
    >>такое in для массива? для словаря? получается? не прада ли удобно,
    >>когда язык объектно-ориентированный? ,-)
    >
    >ааа я понял НОРМАЛЬНОЕ ООП это когда поддерживается перегрузка операторов! Надо же
    >

    и это тоже :)
    но если конструктор может вернуть не объект, то, извините, никак не ООП. возможно, это что-то очень хорошее, но всё же не ООП точно.

     
  • 5.28, JIP (??), 15:42, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >> Perlовик напишет if ($a=~/text/)
    >> Питонщик напишет if 'text' in a
    >> Что понятней?
    >
    >мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
    >"а" - то ли массив, то ли объект. А о том,
    >что это скалярная переменная думается в самую последнюю очередь.

    да, без перлового контекста if ($a=~/text/) и познаний в области питонокодерства трудно сказать что такое "а"

    стоит различать условия <code>if $a eq 'text'</code> и <code>if $a =~ /text/</code>
    язык Кенни (мультперсонаж из южного парка) не навязывает нам регэкспы. регэкспы используются строго по назначению

     
     
  • 6.30, Zoo (??), 16:08, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >[оверквотинг удален]
    >>мне первый вариант гораздо понятней. Во втором варианте вообще непонятно что такое
    >>"а" - то ли массив, то ли объект. А о том,
    >>что это скалярная переменная думается в самую последнюю очередь.
    >
    >да, без перлового контекста if ($a=~/text/) и познаний в области питонокодерства трудно
    >сказать что такое "а"
    >
    >стоит различать условия <code>if $a eq 'text'</code> и <code>if $a =~ /text/</code>
    >язык Кенни (мультперсонаж из южного парка) не навязывает нам регэкспы. регэкспы используются
    >строго по назначению

    вы кажется не поняли...
    if 'text' in a
    работает как
    if ($a=~/text/)
    а не как
    if $a eq 'text' # рекомендую всегда ставить скобки
    только ищется не совпадение регэкспа, а вхождение подстроки, что на много эффективнее.

    а что такое "а" трудно понять только людям, чей мозг съел Перл :-) ну или bash :-)))

     
     
  • 7.32, squirL (??), 23:51, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    ну лично я бы использовал index(STR, SUBSTR) :) а не регексп. использовать регекспы для поиска фиксированной строки, а не шаблона - глупо.
     
  • 4.35, Аноним (1), 09:46, 25/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А зачем он ДАЁТ? ,-)
    >
    >Кроме того, Perl часто провоцирует нечитабельность:
    >- требование (пуcть и не жёсткое) распихивать каждый класс в отдельный файл
    >
    >- поощрение использования regexp-ов там где нужно и там где не нужно
    >
    >  пример:
    >  Perlовик напишет if ($a=~/text/)
    >  Питонщик напишет if 'text' in a

    первый вариант более понятен

    >  Что понятней? Я молчу о производительности.

    используй index или substr

    >- можно продолжать... но суть в том, что Perl специально подталкивает писать
    >непонятно.
    >
    >Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример
    >исключений

    use Error qw(:try);
    и будут тебе исключения

    >Логика программы становится менее понятна из-за "автооживления" переменных.

    use strict;

    >Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else,
    >есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли
    >понять код, в котором такое используется?

    не используй unless в таком контексте

    еще есть вопросы???

     
     
  • 5.38, Zoo (??), 12:16, 25/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Кроме того, в Perl нет многих механизмов, повышающих понятность кода; на пример
    >>исключений
    >
    >use Error qw(:try);
    >и будут тебе исключения

    вы в этот модуль заглядывали?
    eval и die -- это не есть исключения!

    >
    >>Логика программы становится менее понятна из-за "автооживления" переменных.
    >
    >use strict;

    вы, я смотрю, просто не в теме немного

    #!/usr/bin/perl -w
    use strict; # возможно это вернул конструктор :-)))
    my $a=undef;
    $a->{'key'}='val';

    ну и что теперь в $a?
    ни -w ни strict не поможет вам отловить это превращение

    >>Не содействет понятности и нелогичность и незаконченность конструкций. На пример, есть if-elsif-else,
    >>есть unless, но нет unless-elsunless-else. Вместо этого есть unless-elsif-else. Легко ли
    >>понять код, в котором такое используется?
    >
    >не используй unless в таком контексте

    это вы не мне скажите, на напишите в perldoc :-)
    а вопрос-то остался: нафига так делать язык?

    >еще есть вопросы???

    все те же :-)

     
  • 2.23, JIP (??), 12:38, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >2. Отсутствует нормальная поддержка объектов

    скромный боянчик:
    "поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой, делегирование, иерархия объектов и два уровня сборки мусора"

    по поводу читабельности кода уже говорили. в хороших проектах perlstyle разработчиков похож и читать легко. в данный момент поддерживаю крупные (десятки тысяч строк) ООП системы реализованные на Perl и вполне ими доволен

     
     
  • 3.25, lad (?), 14:43, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>2. Отсутствует нормальная поддержка объектов
    >
    >скромный боянчик:
    >"поддерживаются классы и объекты, одиночное и множественное наследование, методы экземпляров и методы
    >классов, переопределение методов, конструкторы и деструкторы, перегрузка операторов, методы-посредники с автозагрузкой,
    >делегирование, иерархия объектов и два уровня сборки мусора"

    А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_ не поддерживаются (например как в C++, C#, Java или PHP).

     
     
  • 4.26, JIP (??), 14:49, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
    >не поддерживаются (например как в C++, C#, Java или PHP).

    есть опыт работы с Java.
    можете вербализовать _НОРМАЛЬНО_?
    очень интересно. пожалуйта.


     
     
  • 5.33, squirL (??), 23:53, 24/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>А никто и не говорил что объекты не поддерживаются. Они просто _НОРМАЛЬНО_
    >>не поддерживаются (например как в C++, C#, Java или PHP).
    >
    >есть опыт работы с Java.
    >можете вербализовать _НОРМАЛЬНО_?

    думаю вряд-ли. это типичная критика на основании "ОБС". реальные недостатки перлового ООП - Анонимусам вряд-ли знакомы :) ну и славно - меньше знаешь, крепче спишь ;)

     
  • 5.34, Аноним (1), 09:41, 25/06/2008 [^] [^^] [^^^] [ответить]  
  • +/
    Да наврятли он то обьяснить сможет что такое _НОРМАЛЬНО_. Как по мне единственный недостаток перла это не типизированные параметры функций - а всё остальное типа НОРМАЛЬНОГО ООП и непонятного кода - сказки для бедных(на ПХП в перемешку с HTML можно писать такое что чёрт ногу сломит)
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:
    При перепечатке указание ссылки на opennet.ru обязательно



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2021 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру