30 игровых скриптов, которые можно написать на языке PHP

>> При статической типизации типы переменных определяются во время компиляции, при динамичесой --- в runtime.

> Хорошо. Согласно этой фразе, вот берем ЯП Java и пишем следующий код:

> int a = 5; AnyClass b = new AnyClass ();

> Согласно Вашему утверждению из первой фразы - переменная a относится к статической типизации, а переменная - к динамической (при условии что к переменной b применяем полиформизм).

> Это неверно.

Тип переменной b - AnyClass. Причём тут присвоенное ей значение?

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

Спасибо за ответ. Изобретение очередного сферического коня, все это.

Как я сразу и говорил - есть устоявшийся набор терминов:

1) Нетипизированные переменные. 2) Типизированные переменные. 3) Пускай тут будет и полиморфизм, на всякий случай. 4) Автоприведение типов. 5) Статический контроль типов.

А все остальное - от лукавого. Хотите доказать обратное - тогда, пожалуйста, скажите, что можно описать вашими формулировками - для программирования, чего нельзя описать этим 5-тью пунктами.

Возможно хоть так удастся что-то понять. Зачем оно и что.

Иначе разговор бесмысленный и будет с моей стороны прекарщен.

> Причём тут присвоенное ей значение?

Это плохо? Максимально полный пример "из жизни", строго типизированный троль? :D

> Одна из самых толковых из тех, что я встречал.

Всё-таки O'Reily, книги этого издательства, насколько я могу судить, можно покупать/читать без опасения даром потерять время/деньги.

Вот если бы ещё посоветовали книгу по лямбда-исчислению и теории категорий...

> Давайте определимся в терминах, из-за путаницы во фразах - мой ответ к Вам на ВАШ ЭТОТ ВОПРОС - упрется СНОВА В СПОРНЫЕ МОМЕНТЫ В ФОРМУЛИРОВКАХ.

Термины для того и существуют, чтобы однозначно определять понятия.

> Не сползай с конкретно заданного тебе вопроса. Где книги, где широкие упоминания этих путанных, противоречивых формулировок?

Они путанные и противоречивые лишь в твоём мозгу.

> Небось в Википедию запостил сам автор данной книги, нет? ;) :D

http://www.google.com.ua/search?hl=en&q=static+typing

Посмотри сколько ссылок.

> Как я сразу и говорил - есть устоявшийся набор терминов:

> 1) Нетипизированные переменные. 2) Типизированные переменные. 3) Пускай тут будет и полиморфизм, на всякий случай. 4) Автоприведение типов. 5) Статический контроль типов.

1, 2) Что это такое? Может, не- и инициализированные переменные?

3) Полиморфизм не имеет никакого отношения к системе типов в этом ракурсе. Просто тип суперкласса совместим со всеми типами субклассов, вот и всё. Но это разные типы.

4) Интенсивность использования typecast и определяет "строгость" языка. А так неявный typecast есть почти в юбом языке (есть ли в Аде?).

5) Да. А есть ещё и динамический. Python, Ruby etc.

> А все остальное - от лукавого. Хотите доказать обратное - тогда, пожалуйста, скажите, что можно описать вашими формулировками - для программирования, чего нельзя описать этим 5-тью пунктами.

3) Не везде есть полиморфизм, да и он тоже бывает разным.

4) Просто сказать, что язык имеет приведение типов --- почти ничего не сказать. Нужно узнать интенсивность его использования.

5) ЯП с динамической типизацией куча. А ещё есть безтиповые языки.

> http://www.google.com.ua/search?hl=en&q=static+typing > Посмотри сколько ссылок.

Вот одна из них:

http://blog.objectmentor.com/articles/2009/07/27/static-typing-vs-dynamic-typing

> Они путанные и противоречивые лишь в твоём мозгу.

Противоречия конкретно указаны, ответа выше не было. Противоречие приведено и в этом моем комментарии, на счет "посмотри сколько ссылок".

Тролло-бздун, пока.

Ответа на мой вопрос нет, чего не хватает "моим" формулировкам.

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

> Просто сказать, что язык имеет приведение типов --- почти ничего не сказать. Нужно узнать интенсивность его использования.

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

> Ответа на мой вопрос нет, чего не хватает "моим" формулировкам.

Ну как же. Есть не только статическая типизация, есть неполиморфные языки или язвки с параметрическим полиморфизмом.

> Вы уж извините меня, но эта Ваша фраза - особенно порадовала, на счет интенсивности, вот так мне нужно знать коэффициент интенсивности, прямо жить без него не могу, что я и говорил - сферический конь в программировании:

Не нужно знать --- ваше дело. Но это всё равно даёт довольно полезную информацию о языке.

1+1.0 выдаст ошибку? А 1+"1"? Или 1 + Integer(1), SmallInt(1) + LongInt(1), NumObj(1) + StringObj(1)? Почему же сферический конь?

>Вывод -- рулит Руби?

Не... Там тоже есть подводные камни :)

>И не совсем понял, почему целые числа оказались не равными.

Потому что «Integer» - это не примитивный тип, а класс целых чисел. Сишный аналог - это «int». Но на него, например, ссылку не передашь, боксинг ему не сделаешь и т.п.

Оператор «==» совершенно ожидаемо для сишника работает в случае примитивного типа «int» и неожиданно - для класса «Integer». Дело в том, что «==» сравнивает не значения объекта, а сами объекты. понятно, что
a = new Integer(1000)
и
b = new Integer(1000)

хоть и будут иметь одно значение внутри себя (.intValue()), но объектами будут разными. И равенство выполняться не будет.

Сравнивать «правильно» можно разными способами:
a.intValue() == b.intValue()
a.compareTo(b)
a.equals(b)

и т.п.

Ситуация осложняется тем, что для повышения производительности младшие 128 целых чисел кешируются системой, так, что

a = new Integer(100)
и
b = new Integer(100)

будут указывать на один объект. Поэтому простой тест с «==» тут сработает и покажет a == b -> True :)

Вот на этом старый сишник и прокололся однажды :) Тест до сотни прошёл - и ладно... А потом народ начал жаловаться, что часть кода в проекте как-то странно работает... :)

...

Потом уже не сам нарывался, но чужие ошибки исправлял, например, в хешах. Запишет кто-то в качестве индекса Short в одном месте, а читает Integer в другом :)

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

Термины strong/weak typing (наверное, правильнее переводить как сильная/слабая типизация) - вполне широко используемые и устоявшиеся.

Вот ещё ссылка по теме: http://www.artima.com/weblogs/viewpost.jsp?thread=7590

> агащаз. я с похапе очень плотно работаю последние 5 лет

Это что же, какие-то несчастные 30 игровых скриптов - 5 лет???!!!

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

трололо!

> трололо!

Слив, я так понимаю, защитан

ога, "язычишко для школьников" и упоминания индусов - это весьма веские аргументы.

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

ты первый начал

Ну дык пых-пых срач же...

> В учебниках описывают - что Integer является объектной оберткой для int.

> С точки зрения эффективности кода - в таких циклах всегда используют простой тип int.

> ... ... ...

я помню давно наблюдал в ремонтном центре сотовых телефонов следущую картину:

клиент забирает свои "почининый" телефон и спрашивает "в чём была неисправность?",

, ему отвечают: "мы поменяли прошивку..."...

...ну и тут начинается феерический скандал.

клиент: "то что вы поменяли прошивку это я понял (я и сам мог её поменять).. но ЧТО БЫЛО НЕИСПРАВНО?!! где бумашка о диагностике. как вы проводили диагностику?"

(а ему опять по кругу отчечают "мы поменяли прошивку......")

Вот сейчас читаю Real World Haskell, привожу оттуда хорошую цитату:

> In academic computer science, the meanings of “strong” and “weak” have a narrowly technical meaning: strength refers to how permissive a type system is. A weaker type system treats more expressions as valid than a stronger type system.

Вот такой "сферический конь в программировании" получается...

Кстати, ведь выходит, что в Haskell неявного приведения типов вообще нет, благодаря классам типов. Это действительно так?

>А вообше, php - язычишко для школьников

Только школьники считают, что языки делятся на языки для школьников и не для оных :)

Нормальные люди просто зарабатывают деньги или пишут для души на том, что им подходит.

> Кстати, ведь выходит, что в Haskell неявного приведения типов вообще нет

По-моему, да. Туда, где нужен Double, Int ты не подсунешь - надо явно приводить. Хотя целочисеньный литерал там, где нужен Double, прокатит. Просто у него тип не Int или Integer, а (Num t) => t.

> благодаря классам типов.

Ммм... поясни.

Ну давай, расскажи нам, какой ты Ъ-школьник и как классно быть php-кодером

2 KRoN73

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

>А вообше, php - язычишко для школьников

- это не аргумент.

>> Кстати, ведь выходит, что в Haskell неявного приведения типов вообще нет

> По-моему, да. Туда, где нужен Double, Int ты не подсунешь - надо явно приводить. Хотя целочисеньный литерал там, где нужен Double, прокатит. Просто у него тип не Int или Integer, а (Num t) => t.

>> благодаря классам типов.

> Ммм... поясни.

Typeclasses. Int и Double --- это производные от типа Num (afair). Поэтому в функциях (*) и (+) можно смешивать Int и Double, так как эти функции принимают Num.

Это мне напоминает полиморфизм из ОО-языков (у этого полиморфизма даже есть какое-то официальное название, которое я уже забыл).

Уважаемые человеки! Повторю свой вопрос: расскажите, пожалуйста, как соотносятся по производительности PHP и Python (без оглядки на выразительность языка и т.п.).

Сферические кони. От 200 у.е. Продвижение коней в Википедии.

555-55-55

> Typeclasses. Int и Double --- это производные от типа Num (afair). Поэтому в функциях (*) и (+) можно смешивать Int и Double, так как эти функции принимают Num.

Int и Double - это инстансы класса типов Num. Поэтому (*) и (+) определены для этих типов.

Но смешивать Int и Double нельзя. Тип (*) :: (Num a) => a -> a -> a. Т.е. оба параметра должны быть одного типа, принадлежащего классу типов Num.

> Int и Double - это инстансы класса типов Num. Поэтому (*) и (+) определены для этих типов.

> Но смешивать Int и Double нельзя. Тип (*) :: (Num a) => a -> a -> a. Т.е. оба параметра должны быть одного типа, принадлежащего классу типов Num.

class (Eq a, Show a) => Num a

data Int
instance Num Int

data Double
instance Num Double

Ну конечно же. То есть существуют типы Num Int и Num Double, а (*) и (+) принимают 2 аргумента, тип у каждого из которых принадлежит к классу типов Num. Теперь должно быть правильно(?) :-)

> (*) и (+) принимают 2 аргумента, тип у каждого из которых принадлежит к классу типов Num

Совсем строго говоря, у функции аргумент всегда один. :) См. currying.

Сигнатура (Num a) => a -> a -> a говорит нам, что не просто типы первого, второго аргумента и результата принадлежат к классу Num, а они ещё и совпадают.

Prelude> :type (*)
(*) :: (Num a) => a -> a -> a
Prelude> let i = 3 :: Int
Prelude> :type (i *)
(i *) :: Int -> Int

Т.е. подставив первый аргумент, мы связали переменную типа а с Int.

Haskell — функциональный декларативный язык программирования, первая версия которого была стандартизована в 1990 году, назван в честь математика Хаскелла Карри, придумавшего слово «монада». Или не придумавшего. Но придумавшего карринг. Или не придумавшего. Но разработавшего теорию категорий для объяснения значения этих слов. Или не разработавшего. Язык Haskell известен благодаря синтаксису, в сравнении с которым пёрл выглядит псевдокодом, а также необходимостью глубокого понимания лямбда-исчисления, замыканий, теории графов, теории категорий, сопромата, анатомии мозга и прочего матана даже для вывода на экран строки «Hello, World!» ...

История

В 1958 году был изобретён первый функциональный язык программирования — Lisp[5]. К 80-м годам прошлого века функциональных языков стало очень много. Каждый задрот считал своим долгом изобрести свой. И вот однажды, в 1987 году было решено создать язык, который бы включал лучшие достижения из всех языков программирования. Собрался специальный комитет из отборнейших задротов и без лишнего шума создали его. Предшественниками хаскеля были ML, SML, Miranda. Кроме того туда добавили немного лиспа, пролога, матана и ещё чего-то там. ...

http://lurkmore.ru/Haskell

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=php&...

И помни, никому нельзя доверять.

ПХП питон... куда мир катится? Perl forever...

> Совсем строго говоря, у функции аргумент всегда один. :) См. currying.

Да-да, конечно. Классная вещь :-)

> Сигнатура (Num a) => a -> a -> a говорит нам, что не просто типы первого, второго аргумента и результата принадлежат к классу Num, а они ещё и совпадают.

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

let i = 2 :: Int
(*) i 3.0
No instance for (Fractional Int) ...
(*) i 2
4

:t (7::Int) * (7::Double)
Couldn't match expected type `Int' against inferred type `Double'

Ну, в принципе так и должно быть. При a :: Int, (Num a) => a -> a -> a становится (Int a) => a -> a -> a.

> http://shootout.alioth.debian.org

Уже смотрел, но там очень синтетические тесты. Они считают множества Мандельброта и т.п.

>Уважаемые человеки! Повторю свой вопрос: расскажите, пожалуйста, как соотносятся по производительности PHP и Python

http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

> (Int a) => a -> a -> a.

Правильно Int -> Int -> Int, т.к. Int - это тип, а не класс. ;)

Кстати, если вдруг вопросы по Хаскеллю будут появляться, можно их спрашивать здесь: http://community.livejournal.com/ru_declarative/ Там много грамотного народа.

> Правильно Int -> Int -> Int, т.к. Int - это тип, а не класс. ;)

Всё стало понятнее, когда я взглянул на тип return: "(Monad m) => a -> m a", и сравнил с (*): (Num a) => a -> a -> a. Вот теперь уже точно понятно, почему можно использовать, например, Int и Double в одном выражении.

> Кстати, если вдруг вопросы по Хаскеллю будут появляться, можно их спрашивать здесь: http://community.livejournal.com/ru_declarative/ Там много грамотного народа.

Спасибо ещё раз.

> http://balancer.ru/tech/forum/2008/08/t63003--proizvoditelnost-yazykov-obektn...

Спасибо. Правда, тоже не совсем "реалистично", но всё равно интересно и полезно (особенно psyco и ruby1.8~ruby1.9).

Ладно, теперь вопрос #2 :)

Почему бОльшая часть хостеров предоставляет только PHP (ну или + ASP)?

>Почему бОльшая часть хостеров предоставляет только PHP (ну или + ASP)?

По причине инерции мышления. Кстати, некоторые девелоперы выбирают пыхпых по той же причине ;)

> Кстати, если вдруг вопросы по Хаскеллю будут появляться, можно их спрашивать здесь: http://community.livejournal.com/ru_declarative/ Там много грамотного народа.

Т.е. http://community.livejournal.com/ru_lambda/

ru_declarative - для продвинутых.

Какой "Относительно Конкретный" парень пожаловал %)

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

>Почему бОльшая часть хостеров предоставляет только PHP (ну или + ASP)?

С разделением прав проще.

Я, например, для Питона вообще не представляю, как сделать отдельный Питоновский сервер для отдельного юзера, кроме как вешать по раздельному fcgi на каждого клиента.

> Какой "Относительно Конкретный" парень пожаловал %)

По моему глубокому убеждению фунциональное программирование - это некий аналог 2D. Если же помимо функций (методов) - используют еще и классы, то получается "новое измерение", 3D.

> Какой "Относительно Конкретный" парень пожаловал %)

По моему глубокому убеждению фунциональное программирование - это некий аналог 2D.

Если же помимо функций (методов) - используют еще и классы, то получается "новое измерение", 3D.

Как правильно использовать 3D - помогает ООП.

Функциональное программирование пытается функции приспособить, использовать - на подобии как объекты, при этом и идут дикие извращения и концепции, как же это сделать.

Многие функциональное программирование привлекает относительно низким порогом вхождения (не нужно учить классы и ООП). "Впереди", при этом - маячат упоминания других про всякие интересные вещи, вход идут графы, метапрограммирование - это то, что смогли всунуть, или пытаются обосновать что-либо в нем, в это старье (функциональное программирование) за десятки лет и почему оно еще не сдохло.

Функциональное программирование появилось раньше ООП. Поэтому нет ничего удивительного, что оно вообще появилось.

Однако стиль написания в функциональном стиле - зачастую сами авторы-проповедники (смотрел презентацию F#) - можно зачастую назвать как "write once" - написал один раз, потом фиг разберешь что написано.

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

Чтобы повысить порог сложности в ДЕСЯТКИ-СОТНИ раз - и было придумано ООП.

Мои "придирки" по поводу надуманности терминов сторонников функционального программирования (и упоминание ими, что смогли найти - только учебника по функциональному языку программирования Хаскель) - как раз и отлично демонстрируют - каково беднягам, что они выдумывают в попытке извращаться, чтобы использовать по сути функции как объекты.

Удачи. :)

> Если же помимо функций (методов) - используют еще и классы, то получается "новое измерение", 3D.

Если уж так, то 3D --- это как раз языки, где есть HOF.

> Функциональное программирование пытается функции приспособить, использовать - на подобии как объекты, при этом и идут дикие извращения и концепции, как же это сделать.

А при чём тут объекты? В ФП данные в общем случае не связаны с алгоритмами.

> Многие функциональное программирование привлекает относительно низким порогом вхождения (не нужно учить классы и ООП).

Ничего себе низкий порог. Я до сих пор не могу ясно представить себе, например, функторы. Объектную концепцию наоборот легче понять по аналогии с реальным миром (состояние + поведение).

> "Впереди", при этом - маячат упоминания других про всякие интересные вещи, вход идут графы, метапрограммирование ...

А что же такое шаблоны C++ или generics в Java? Откуда взялись замыкания, кортежи?

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

Наверное по той же причине, по которой не "сдохла" математика и информатика, старьё же.

> Чтобы повысить порог сложности в ДЕСЯТКИ-СОТНИ раз - и было придумано ООП.

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

> Мои "придирки" по поводу надуманности терминов сторонников функционального программирования (и упоминание ими, что смогли найти - только учебника по функциональному языку программирования Хаскель) - как раз и отлично демонстрируют - каково беднягам, что они выдумывают в попытке извращаться, чтобы использовать по сути функции как объекты.

Как эти термины связны с ФП? И потом, опишите уже язык Python только своими терминами.

Мне в своё время понравилась книга Буча про ООП, он там пишет, что подобно тому, как взявший в руки молоток начинает видеть вокруг только гвозди, человек, понявший ООП, начинает во во всём видеть объекты. Это очень меткое замечание, но не нужно при этом думать, что мир состоит из гвоздей и уж тем более замахиваться молотком на людей :-)

Ответы притянуты за уши, большинство вообще не притянуты никуда. Извините.

> Мне в своё время понравилась книга Буча про ООП, он там пишет, что подобно тому, как взявший в руки молоток начинает видеть вокруг только гвозди, человек, понявший ООП, начинает во во всём видеть объекты. Это очень меткое замечание, но не нужно при этом думать, что мир состоит из гвоздей и уж тем более замахиваться молотком на людей :-)

Чтение книги Буча не подразумевает понимание того, что написано дальше 3-ей, или какой там одно из 1-ых страниц, на которой приведена эта фраза. ;)

У меня есть свой паттерн проектирования. Может не так уж нужный. Может за те годы, которые прошли после того как я его придумал - я бы что-то переформулировал в нем, в общем Ваше стремление видеть в собеседника школьника - не оправдано.

> Ответы притянуты за уши, большинство вообще не притянуты никуда. Извините.

Какие именно ответы и что именно в них неверно?

> Чтение книги Буча не подразумевает понимание того, что написано дальше 3-ей, или какой там одно из 1-ых страниц, на которой приведена эта фраза. ;)

Чтение любой книги подразумевает понимание хотя бы части написанного. Или вы хотите сказать, что я читал только 1-3 страницы? Ну и как вы это выяснили?

> У меня есть свой паттерн проектирования.

Свой? А можно описание? Или что здесь имеется ввиду под "паттерном проектирования"?

> ... в общем Ваше стремление видеть в собеседника школьника - не оправдано.

Где мною было проявлено это стремление?

P.S. Я всё ещё жду описание Python'а.

>> Чтение книги Буча не подразумевает понимание того, что написано дальше 3-ей, или какой там одно из 1-ых страниц, на которой приведена эта фраза. ;)

> Чтение любой книги подразумевает понимание хотя бы части написанного. Или вы хотите сказать, что я читал только 1-3 страницы? Ну и как вы это выяснили?

А я это выяснил? Вот так прямо взял и выяснил? Не намекнул, об этом, в пику того как Вы пытались намекать о противоположном?

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

Мозг где-то вверху стопорится, там в одном неймспейсе - 10.000 функций, придуманных другими. Но свои концепции не образуются, попытки метапрограммированием связать что-то - вызывает чудовищный скрежет по всему корпусу высокоуровневого центра мозговой деятельности.

Между тем, оперируя объектами, такими так Земля, Лес, Пастух - Вы бы смогли сэмулировать практически любую предметную область, при этом иметь и пошаговый отладчик и простоту оперирования нужными предметными областями, и любым рефакторингом в них, за долю секунды.

> Какие именно ответы и что именно в них неверно?

У меня нет 3-4 часов, чтобы в деталях изложить для Вас все и еще часов 10, нужных на то, чтобы Вы не съзжали с вопросов и не уезжали на своем мягком месте в ближайший ельник, с крольчихами и блэкджеком на питоне.

> P.S. Я всё ещё жду описание Python'а.

А почему не ждете от меня описания межконтинентальной баллистической ракеты?

В чем разница, я же и не то, и не то не обещал?

:D