The OpenNET Project / Index page

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

Новый язык программирования Nesla, похожий на JavaScript и PHP.

06.06.2007 17:20

Вышла новая версия языка программирования Nesla 0.6.0.

NullLogic Embedded Scripting Language (Nesla) - скриптовый язык программирования, интерпретатор которого распространяется под лицензией GNU GPL. Проект Nesla вырос из парсера конфигурационных файлов, по синтаксису язык похож на JavaScript и PHP. Размер архива с исходными текстами - 94 Кб.

Краткое описание на русском языке и пример кода можно найти на данной странице. Список изменений в версии 0.6.0: на английском, на русском

  1. Главная ссылка к новости (http://nesla.sourceforge.net/n...)
Автор новости: Kit
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/11019-script
Ключевые слова: script
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (45) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Злобный Anonymous (?), 08:33, 07/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Главное чтобы не был таким же дырявым.
     
  • 1.2, A (?), 09:11, 07/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Неминуемо будет таким же дырявым. Что за мода создавать языки из всяких парсеров? (напомню, что PHP (изначально Personal Home Page Tools) появился из приблуды, которую Расмус Лердорф написал, чтобы анализировать кто читал его резюме!)
    Все эти изврашения проистекают из двух вещей: 1) молодым и горячим лень читать документацию и изучать уже существующие решения 2) молодым и горячим хочется самим попрогать языки. Через эту фазу проходит любой программист, написание языка -- прекрасное упражнение (особенно, если автор потрудился изучить теорию этого дела и строит действительно полноценный, непротиворечивый, регулярный синтаксис) и очень увлекательное занятие. Но другие молодые и горячие начинают использовать эти недоязыки (первый блин, как правило, комом, а второго часто уже не бывает).
     
     
  • 2.3, gmm20 (??), 14:45, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    есть всего два основных метода создания языков 1 сверху-вниз, через комитет, с... большой текст свёрнут, показать
     
     
  • 3.4, Бизон (?), 15:29, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    2gmm20

    у вас очень ограниченный кругозор:)
    >скрипт cgi-bin/perl будет намного медленнее работать
    cкрипт на перле а поставлю против аналогичного скрипта на ПХП в любой день недели - и не рассказывайте сказки из тех тестов что я видел всегда выигрывал перл если у вас есть альтернативные сравнения - пожалуйста дайте линку.

    > apache/mod_perl - требует для каждого проекта свой собственный екземпляр apache
    это шутка?
    mod_perl с mod_php вообще не имеет смысла сравнивать. скрипт на Mod_perl работает как модуль апача отсюда и уйма приемуществ - в ПХП всё равно такой гибкости не добиться


    >Ruby on Rails всеравно дороже будет, чем PHP
    он уже продаётся?? не покупайте!!! я вам бесплатно пришлю

    >да, в 5-й версии PHP много идей понадергали из Python и Java,
    например?

     
     
  • 4.5, gmm20 (??), 17:04, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    [...]

    >> скрипт cgi-bin/perl будет намного медленнее работать

    > cкрипт на перле а поставлю против аналогичного скрипта на ПХП в любой день недели
    > и не рассказывайте сказки из тех тестов что я видел всегда выигрывал перл
    > если у вас есть альтернативные сравнения - пожалуйста дайте линку.

    использование perl через cgi интерфейс - это:

    1. создание нового процесса
    2. запуск интерпретатора perl
    3. компиляция исходного кода perl в внутреннее представление (байт-код)
    4. интерпретация (выполнение) байткода
    5. завершение процесса perl

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

    при исполнении php скриптов через mod_php - новые процессы не создаются,
    в результате нагрузка на процессор гораздо меньше. на виртуальном хостинге,
    где висит несколько сотен различных сайтов - эта разница очень хорошо видна.

    >> apache/mod_perl - требует для каждого проекта свой собственный екземпляр apache

    > это шутка?

    это правда.

    > mod_perl с mod_php вообще не имеет смысла сравнивать.
    > скрипт на Mod_perl работает как модуль апача отсюда и уйма приемуществ
    > - в ПХП всё равно такой гибкости не добиться

    вот из-за этой "гибкости" mod_perl и нужен каждому пользователю свой собственный apache.

    [...]

    >> в 5-й версии PHP много идей понадергали из Python и Java

    > например?

    зачем?

    (зачем мне это нужно - "метать бисер" перед ....... ?)

     
     
  • 5.7, Бизон (?), 21:10, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Не понятно какого хрена сравнивать CGI и mod_php ????? СGI имеет отношение к перлу такое же как и пхп.
    Ну с mod_perl вы вообще не имели дела поэтому не будем о нём и спорить - слив засчитан.

    > в 5-й версии PHP много идей понадергали из Python и Java
    > например?
    > зачем?

    Ещё один слив?? Просто я всё на яве да на перле - может уже и пхп чтото вкусное предложить может ?? Помню помню как ПХП мне предлагало для каждой базы свой набор ф-ций использовать а  смарти по умолчанию юзало фигурные скобки.

     
  • 5.37, _Nick_ (??), 19:29, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > apache/mod_perl - требует для каждого проекта свой собственный екземпляр apache
    > это правда.

    ты тоже там же пасешьсо?? а че вы тогда спорите? :)

    читай щас если до сих пор ниасилил:
    "mod_perl — дополнительный модуль для веб-сервера Apache, внедряющий интерпретатор языка Perl в Apache, и позволяющий избежать значительных накладных расходов на запуск Перла для обработки каждого запроса."

    сорс: http://ru.wikipedia.org/wiki/Mod_perl

     
  • 4.6, Oles (?), 18:34, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >cкрипт на перле а поставлю против аналогичного скрипта на ПХП в любой
    >день недели
    ИМЕННО, друг мой ;)
    А написать на PHP аналог твоего скрипта на перле будет проблематичнее для того,
    кто будет врубаться в то, что делает твой скрипт на перле. Потому и уход программера из проекта и приход нового занимает время, и для PHP это время адаптации будет заметно меньше ;). Синтаксис PHP _намного_ легче и понятнее, он писался для людей, а не как альтернатива sh/awk/sed (которые также очень далеки от programmer-friendly), а языки одного и того же класса. Зачем же выбирать перл? "Тому що конкретний" (С) ?

     
     
  • 5.8, Бизон (?), 21:14, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Синтаксис PHP _намного_ легче и понятнее, он писался для людей

    бла бла бла
    "Какие ваши доказательства?"(C)

    >>Зачем же выбирать перл?

    зайдите на cpan.org и поймёте зачем выбирать перл ;)

     
     
  • 6.18, don_oles (??), 09:06, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>>Синтаксис PHP _намного_ легче и понятнее, он писался для людей
    >
    >бла бла бла
    >"Какие ваши доказательства?"(C)

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

    Доказательства. Пожалуйста. Технические. Сложные струкрутры данных $a[a][b] или $a->{b}->{c}. А ведь в перле два вида массива! Далее. grep или in_array? Что будет понятнее тому кто знает хорошо только английский? Слово grep понятно только тем кто видел юниксы. == или eq ? Вот эти ne/gt/eq для строк просто маразм - тяжёлое наследие sh/awk/sed ;-) ЭТО ПЕРЛ ВЫЛЕЗ ИЗ ШЕЛА ;) Далее q/qw/qq/qx/qw ? Это английский? Это албанский. И таких примеров много.

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


    >>>Зачем же выбирать перл?
    >
    >зайдите на cpan.org и поймёте зачем выбирать перл ;)
    И что это доказывает? Ой ли мама.
    Ты знаешь почему PEAR беднее? Потому что без PEAR уже всё есть нужное в нескольких десятках модулей (которые уже подгружены на момент запуска скрипта). Так что CPAN это для тех, у кого нет PHP.


     
     
  • 7.30, Бизон (?), 18:51, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ааа ну если вы пишите программы которые используют несколько десятков модулей - вопросов больше не имею - продолжайте и ладбше писать сайты про собаку - только вот в такие дискуссии больше встревать не рекомендую


     
  • 5.9, гость (?), 21:38, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Потому
    >и уход программера из проекта и приход нового занимает время, и
    >для PHP это время адаптации будет заметно меньше ;).

    Молодец что смайлик поставил: нельзя жу серьёзно считать недоучку портящего интернет очеред ным убожеством с помощью пхп Программистом.

     
     
  • 6.19, don_oles (??), 09:15, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >>Потому
    >>и уход программера из проекта и приход нового занимает время, и
    >>для PHP это время адаптации будет заметно меньше ;).
    >
    >Молодец что смайлик поставил: нельзя жу серьёзно считать недоучку портящего интернет очеред
    >ным убожеством с помощью пхп Программистом.

    Открою тебе страшную тайну: бизнесмену как-то всё равно кто помогает ему делать деньги быстро, и что думают про этого человека другие недопрограммисты. Счастье ведь не в само-крутости.

     
     
  • 7.22, belkin (?), 10:50, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Открою тебе страшную тайну: бизнесмену как-то всё равно кто помогает ему делать
    >деньги быстро, и что думают про этого человека другие недопрограммисты. Счастье
    >ведь не в само-крутости.

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

     
     
  • 8.24, Oles (?), 14:50, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Не в бровь а в глаз Вот именно про _качества_ средств и идётся речь И время со... текст свёрнут, показать
     
     
  • 9.26, gmm20 (??), 16:10, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    обычно оценивают качество _реализации_ языков программирования по количеству кр... текст свёрнут, показать
     
     
  • 10.28, Oles (?), 16:47, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Вот есть язык brainfuck На википедии можешь поискать Уверен - у него самый бе... текст свёрнут, показать
     
     
  • 11.29, gmm20 (??), 18:11, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    далеко не у всех хостеров стоит последняя версия из 4-й или 5-й ветки на это ещ... большой текст свёрнут, показать
     
  • 9.31, Бизон (?), 18:54, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    бугага - морально устарел - раскажите об этом в yahoo ... текст свёрнут, показать
     
  • 9.34, belkin (?), 11:13, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    Программа пишется для последующего выполнения Она должна качественно работать, ... текст свёрнут, показать
     
  • 4.36, _Nick_ (??), 19:25, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >mod_perl с mod_php вообще не имеет смысла сравнивать. скрипт на Mod_perl работает
    >как модуль апача отсюда и уйма приемуществ - в ПХП всё
    >равно такой гибкости не добиться

    где вы такие покосы нашли??

    а как же по-вашему работает mod_php как не модуль апача???

     
  • 3.10, гость (?), 21:43, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ...
    >причем, первая версия PHP была написана на Perl
    ...
    >когда создавались те же языки PHP и JavaScript аналогов с такой же
    >функциональностью
    >просто не существовало. Javascript - исполняется в browser'е на стороне клиента,
    >PHP - специализированный язык для разработки веб-приложений.

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

     
     
  • 4.11, gmm20 (??), 22:19, 07/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >> первая версия PHP была написана на Perl
    ...
    >> когда создавались те же языки PHP и JavaScript
    >> аналогов с такой же функциональностью просто не существовало.
    >> Javascript - исполняется в browser'е на стороне клиента,
    >> PHP - специализированный язык для разработки веб-приложений.

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

    Perl - это универсальный язык.

    и если бы существующие на тот момент cgi/perl и mod_perl удовлетворяли
    все потребности разработчиков и хостеров, не было бы причин создавать PHP и mod_php.

    cgi/perl - динамические сайты будут тормозить, из-за особенностей интерфейса CGI
    mod_perl - каждому клиенту нужно выделять свой собственный экземпляр apache.

    сайты, где был в основном статический контент - им было достаточно cgi/perl для динамики,
    крупные проекты - использовали mod_perl и выделенный сервер, например, тот же Amazon.com

    и тех и тех сайтов - примерно по 10-15%.

    mainstream же - это проекты которым cgi/perl - уже мало, а mod_perl - еще много.
    если бы не существовало этой незаполненной ниши, то PHP никогда не стал бы популярным.

    кроме того, если посмотреть на ситуацию с точки зрения хостинговых компаний:
    mod_php - это самый оптимальный способ упаковать наибольшее количество динамических
    сайтов, размещенных на виртуальном хостинге на один физический сервер.

     
     
  • 5.13, Бизон (?), 02:06, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    господин что нибудь слышал о nginx, lighttpd, FastCGI, mod_perl(Apache::Registry, Apache::PerlRun)?

    интересно а какие причины создания языка Nesla?? но ведь создают!!!


     
     
  • 6.14, gmm20 (??), 03:02, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    > господин что нибудь слышал о nginx, lighttpd,
    > FastCGI, mod_perl(Apache::Registry, Apache::PerlRun)?

    PHP создавался в 1995-1996 году, nginx появился где-то в 2004-2005.
    кстати, как nginx может ускорить обработку формы cgi/perl скриптом?

    так же и остальные "модные технологии" вряд ли существовали
    в 1993-1995 году и могли как-то влиять на ситуацию в то время.

    PS кстати, лично для тебя, полезная информация, к размышлению:
    http://www.microchip.ru/phorum/read.php?f=2&i=126600&t=126600

     
     
  • 7.21, Бизон (?), 10:08, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >> господин что нибудь слышал о nginx, lighttpd,
    >> FastCGI, mod_perl(Apache::Registry, Apache::PerlRun)?
    >
    >PHP создавался в 1995-1996 году, nginx появился где-то в 2004-2005.
    >кстати, как nginx может ускорить обработку формы cgi/perl скриптом?

    Никак - он CGI вообще не поддерживает и вы будете поражены там нету mod_perl!(вы ещё стоите на ногах?)
    Вы запарили своим CGI - это уже не актуально лет 5.


    >PS кстати, лично для тебя, полезная информация, к размышлению:
    >http://www.microchip.ru/phorum/read.php?f=2&i=126600&t=126600

    ЗЫ я с вами на брудершафт не пил. Поэтому не тебя а вас. Вы недоучка впринципе я другого от ПХПшника и не ожидал - хотя и бывают приятные исключения

     
  • 6.16, uldus (ok), 08:57, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >интересно а какие причины создания языка Nesla?? но ведь создают!!!

    Минимальный размер интерпретатора и возможности достаточные для большинства embedded решений.

    По поводу PHP gmm20 говорит верно, PHP был ответом на образовавшийся вакуум - отсутствие элементарного инструмента, дающего возможность любому непросвященному скопировать пару готовых строк кода прямо в свой HTML без лишних усложнений и особо не разбираясь, а админу получить готовое оптимальное массовое решение вида "все включено".

     
  • 5.20, masted (ok), 09:25, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >mainstream же - это проекты которым cgi/perl - уже мало, а mod_perl - еще много.

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

     

  • 1.12, JIP (??), 22:32, 07/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "девять из десяти наркоманов вибирают ПэХаПэ"

    интересна область применения языка (ниша которую он занимает), а все эти ритуальные танцы вокруг синтаксических наворотов можно проигнорировать

    по поводу юзерфрендли: в процессе биоэволюции выжили теплокровные уважающие perlstyle и соотвественно пренебрежительно относящиеся к этому явлению. проще так сказать - оба пути ведут в АД (при желании можно выбрать альтернативный метафизический объект)

     
     
  • 2.15, kvas (?), 06:40, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ...
    > по поводу юзерфрендли: в процессе биоэволюции выжили теплокровные уважающие perlstyle и
    > соотвественно пренебрежительно относящиеся к этому явлению. проще так сказать - оба пути
    > ведут в АД (при желании можно выбрать альтернативный метафизический объект)

    Блин! Ну зачем же сразу Актив Директорием пугать? :) Я лучше альтернативный объект выберу!
    А по поводу языков - с тех пор, как TopSpeed (читай - Йенсен) ушла с этого рынка, так приличных и не было (на моей памяти). Я по сию пору в их Modula-2 с объектными расширениями влюблён, но толку-то, один фиг приходится писать на Цэ, ЦэПэПэ и прочих извратах.
    И правильно тут юзерфрендливость упомянута, раз уж во всём мире господствующее положение на рынке OS заняли Windows, то не надо удивляться, что на рынке языков всё смещается к недопрограмист-френдли языкам типа php. Общая тенденция, так сказать.

     

  • 1.17, A (?), 08:58, 08/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я не хочу спорить про то, что лучше перл или пхп. Кто знает и пхп и мод-перл, тот и так понимает, что мод-перл гибче и проще в поддержке, чем пхпшная мешанина из кода и данных. Я хочу сказать про другое.

    Действительно, есть языки, которые развиваются хаотично. Они все ущербны.

    Здесь был упомянут С, пример на С:
    i=a/*b; /* bug */
    это "комментарий с /* внутри" или "делить на указатель"? разные компилляторы понимают это поразному потому, что это не поддаётся логическому пониманию! это нерегулярность языка -- элементаная непродуманность синтаксиса. когда начинается ОО таких глюков становится ещё больше из-за конструкций типа >>.

    Здесь был упомянут перл. Хвала Лари, перл долго был регулярным, но с появлением в нём ОО, он эту регулярность значительно утратил. пример:
    1) созадём m.pm с методом new
    2) пишем скрипт
    use m;
    всё работет
    3) добавлем вторую строчку
    $a=m->new;
    видим странные ошибки
    Кстати (для знатоков) строка $a=m->new<-m; сработает без ошибок, но сделает не то, что модно подумать :-)

    Я утверждаю, что все хаотично развивающиеся языки противоречивы и могу привести ещё кучу примеров. Чтобы создать нормальный язык надо создавать язык, а не парсер или считалку просмотов резюме. Тогда получится руби, питон, смолток, tcl, лисп, хаскель...

     
     
  • 2.25, GlebVt (?), 15:33, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Здесь был упомянут С, пример на С:
    >i=a/*b; /* bug */
    >это "комментарий с /* внутри" или "делить на указатель"?

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

    i = a / *b;
    а можно так, если пробелы не любим:
    i = a/(*b);

    не понимаю где тут "ущербность"...

     
     
  • 3.27, A (?), 16:16, 08/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    в том и есть :-)
    Елси бы в спецфикации было написано "знак '/' всегда надо отделать пробелами от переменных", это был бы дурацкий язык. Но если про это не написано ничего, но иногда возникают ситации, когда без пробелов прога даже не разберётся на токены(!!), это уже полная попсня. Согласитесь, что создатели языка не продумали эту ситуацию. А не продумали они её потому, что модель синтаксиса не была построена. Делалось так, как казалось правильным. Это даёт всегда только прилизительно правильный результат. Из серии 5x5=25, 6x6=36, тогда и 7x7=47. Почти правильно :-)
     
     
  • 4.32, GlebVt (?), 10:13, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    ну мне оно не мешает. именно знак "/".
    больше мешает упомянутый раньше '>>' & '<<'. особенно когда шаблоны используешь. вроде и пробел не смотрится, а вроде как и надо :)
     
  • 4.33, GlebVt (?), 10:14, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    а вобще, если бы все было идеально, было бы скучно жить )
     
  • 4.35, belkin (?), 11:27, 09/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >в том и есть :-)
    >Елси бы в спецфикации было написано "знак '/' всегда надо отделать пробелами
    >от переменных", это был бы дурацкий язык. Но если про это
    >не написано ничего, но иногда возникают ситации, когда без пробелов прога
    >даже не разберётся на токены(!!), это уже полная попсня. Согласитесь, что
    >создатели языка не продумали эту ситуацию. А не продумали они её
    >потому, что модель синтаксиса не была построена. Делалось так, как казалось
    >правильным. Это даёт всегда только прилизительно правильный результат. Из серии 5x5=25,
    >6x6=36, тогда и 7x7=47. Почти правильно :-)

    -------------
    BU> А зачем все усложнять? Был скажем такой язык PL/1 - В нем кучу всего
    BU> напихали.
    BU> И кто им сейчас пользуется?
    Те, кто не программирует 1 проблемный комплекс из сотен программ на смеси
    языков, где каждый язык - для своей цели. :)
    В частности, он давно есть для вин, для ос2 и т.п., и в нем есть практически
    все для выживания даже в подобных системах, включая все окологуишные примочки
    и кросс-трансляцию для системы команд указанной при трансляции платформы (390,
    например).
    В общем, начиная с оптимайзера от ИБМ, у меня не было особых претензий к этому
    языку. f - это была песня, и я её материл, но даже эту песню я б, наверное,
    предпочел С. :)
    Вообще из "верхних", то есть - наиболее прилично выглядящих языков я б назвал
    рекс и ада. Первый, к сожалению, процедурный, как это и определено его
    стандатом, второй - я не видел компилятора, который бы мне понравился. Ещё
    есть алгол68, который был реализован для всех известных мне платформ как бы не
    раньше С, и по списку возможностей пересекается с ада более, чем на 90%.
    ---------------

     
  • 2.38, Cub (?), 06:20, 10/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Кстати (для знатоков) строка $a=m->new<-m; сработает без ошибок, но сделает не то, что модно подумать :-)

    Не затруднит ли сэра объяснить для не-знатоков, в чем заморочка?

     
     
  • 3.39, _Nick_ (??), 06:56, 10/06/2007 [^] [^^] [^^^] [ответить]  
  • +/

    >Не затруднит ли сэра объяснить для не-знатоков, в чем заморочка?

    ГЫ
    Квадратный, это ты? %)

     
  • 3.40, A (?), 09:00, 13/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    могу подсказать ,-)
    по той же самой причине будут точно так же глючить модули с названиями q, qq, qx... догоняете? ,-)
     
     
  • 4.42, nordicdyno (?), 14:46, 19/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >могу подсказать ,-)
    >по той же самой причине будут точно так же глючить модули с
    >названиями q, qq, qx... догоняете? ,-)


    так будет работать:

    $a="m"->new;

    :D

    З.Ы.
    Ну ключевые и зарезервированные слова во многих языках нежелательно использовать так-то, если не хочется "невразумительных ошибок" :)

     
  • 2.43, nordicdyno (?), 14:50, 19/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Здесь был упомянут перл. Хвала Лари, перл долго был регулярным, но с
    >появлением в нём ОО, он эту регулярность значительно утратил. пример:
    >1) созадём m.pm с методом new
    >2) пишем скрипт
    >use m;
    >всё работет
    >3) добавлем вторую строчку
    >$a=m->new;
    >видим странные ошибки
    >Кстати (для знатоков) строка $a=m->new<-m; сработает без ошибок, но сделает не то, что модно подумать :-)
    >

    и еще... неужели есть еще люди не использующие в скриптах perl (я не беру случаи применения ключа -e :)
    use strict;
    use warnings;

    (безумству храбрых поем мы песТню :)

    вот с ними второй пример работать-то и не будет =D

     

  • 1.41, JIP (??), 21:16, 14/06/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Увидел объявление на стене любимой общаги: "Программист 1С - это будущее!". Креативно, но до творчества Пелевина (с эстетикой березового Sprite) не дотягивает :)
     
     
  • 2.44, nordicdyno (?), 14:51, 19/06/2007 [^] [^^] [^^^] [ответить]  
  • +/
    >Увидел объявление на стене любимой общаги: "Программист 1С - это будущее!". Креативно,
    >но до творчества Пелевина (с эстетикой березового Sprite) не дотягивает :)
    >

    если верить пост-панку, то именно такое будущее нас и ждет :)

     
  • 2.46, VVZ (??), 17:43, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >Увидел объявление на стене любимой общаги: "Программист 1С - это будущее!". Креативно,
    >но до творчества Пелевина (с эстетикой березового Sprite) не дотягивает :)

    Не дотягивает, но смахивает на правду...
    Достаточно почитать вакансии. За ковыряние в 1С платят гораздо больше, чем за тот же PHP. Плюс, спрос на 1С-ников на порядок больше.

    Вот такие пирожки. А вы PERL, PHP...

    (кстати, сейчас делаю один проект на PHP (до этого 7 лет писал на PERL'е) - дык, выходит, что в PHP нужно разделять код от содержимого. Другими словами, основное преимущество PHP - возможность встраивать код в страницы, сейчас всеми однозначно расценивается как недостаток...)

     
     
  • 3.47, nordicdyno (?), 19:30, 11/03/2008 [^] [^^] [^^^] [ответить]  
  • +/
    >>Увидел объявление на стене любимой общаги: "Программист 1С - это будущее!". Креативно,
    >>но до творчества Пелевина (с эстетикой березового Sprite) не дотягивает :)
    >
    >Не дотягивает, но смахивает на правду...
    >Достаточно почитать вакансии. За ковыряние в 1С платят гораздо больше, чем за
    >тот же PHP. Плюс, спрос на 1С-ников на порядок больше.
    >

    ну про "порядок" это врят ли, а вообще за ковыряние в гуано всегда доплачивали ибо желающих не так много, а профи среди них и того меньше (это я про 1С)

    >Вот такие пирожки. А вы PERL, PHP...
    >
    >(кстати, сейчас делаю один проект на PHP (до этого 7 лет писал
    >на PERL'е) - дык, выходит, что в PHP нужно разделять код
    >от содержимого. Другими словами, основное преимущество PHP - возможность встраивать код
    >в страницы, сейчас всеми однозначно расценивается как недостаток...)

    Основое преимущестово PHP на данный момент большое количество доступных кодеров (об их уровне умолчу).
    Кстати если посмотреть по ЗП -- нынче хороших Perl-овиков с руками отрывают и предлагают неплохие деньги ;)
    (Для PHP-профи тоже не все так плохо ибо они (профи) всегда востребованны)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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