Язык программирования, где нет типов. Ваше отношение?

← →
12 © (2010-04-13 09:46) [0]

аля PHP, VB

← →
crux (2010-04-13 09:54) [1]

>Язык программирования, где нет типов.

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

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.69.5966&rep=rep1&type=pdf

← →
TUser © (2010-04-13 09:54) [2]

Нестрогая типизация - хорошо для небольших программ, скртипты там всякие. Список языков какой-то странный, писал бы уж - Perl, JavaScript :-)

← →
test © (2010-04-13 09:55) [3]

VB типы найдены и простейшие, и сложные, и классы. Изначально типы тоже вполне были. Каких типов не хватает?

← →
12 © (2010-04-13 10:04) [4]

> Каких типов не хватает?

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

PHP учу..

← →
brother © (2010-04-13 10:10) [5]

1.
> Назначение,

это в комментарии должно быть (если логика сложная)
2.

> и вообще что от нее ожидать

см 1.
а
> где нет типов

это, имхо, хорошо, за ними следить не надо ;)
PHP +5!

← →
TUser © (2010-04-13 10:12) [6]

ааа, ну пиши с юмором

if (gettype($a)=="integer" && gettype ($b)=="integer")
{
$c=$a+$b;
$c = (integer) $c;
}

← →
tesseract © (2010-04-13 10:13) [7]

> Назначение, тип, и вообще что от нее ожидать - хз..

Это уже не язык - это уже ручки писателя. Если есть динамическая типизация - есть и динамическая информация о типе. Удобно например проверять что в переменной записано.

← →
TUser © (2010-04-13 10:14) [8]

else
{
die ("invalid script, call the webmaster");
}

← →
Mystic © (2010-04-13 10:27) [9]

Нормально отношусь. То, что переменные всплывают, так это в любом языке такого эффекта можно добиться. Типы тут не причем :) Например,

uses SysUtils; ... DecimalSeparator := "."; // Всплыла переменная

← →
test © (2010-04-13 10:28) [10]

12 © (13.04.10 10:04) [4]
Это уже кто как пишет, можно ясно красиво на PHP писать, можно крайне запутано и коряво на Delphi, язык тут ни причем.

← →
sniknik © (2010-04-13 11:12) [11]

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

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

← →
tesseract © (2010-04-13 11:20) [12]

> вообще из-за необязательности объявления переменных

В PHP вроде можно Strict включить ? Очень полезная вещь.

← →
KSergey © (2010-04-13 11:21) [13]

если не вру, в VBScript есть спецовая деректива, отключающая это безобразие.

> sniknik © (13.04.10 11:12) [11]
> php-стов больше всего ошибок, допустят опечатку, она засчитается новой переменной, не инициализированной

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

← →
antonn © (2010-04-13 11:30) [14]

> Язык программирования, где нет типов. Ваше отношение?

положительно, в пхп легкая и быстрая разработка

← →
Anatoly Podgoretsky © (2010-04-13 11:49) [15]

> tesseract (13.04.2010 11:20:12) [12]

Те кто включает Strict подлежит презрению коллег.

← →
test © (2010-04-13 11:53) [16]

Anatoly Podgoretsky © (13.04.10 11:49) [15]
Неправда ваша, их отправляют на курсы чтобы искоренить ))

← →
brother © (2010-04-13 11:55) [17]

> на курсы чтобы искоренить ))

на курсах их отстреливают?)

← →
tesseract © (2010-04-13 11:56) [18]

> положительно, в пхп легкая и быстрая разработка

Скорость разработки обратно пропорциональна времени отладки.
Время отладки составляет 120 % сроков разработки проекта.

← →
sniknik © (2010-04-13 12:11) [19]

> В PHP вроде можно Strict включить ?
может быть, не знаю, если есть и если бы писал я, то обязательно бы включил. но...

← →
sniknik © (2010-04-13 12:14) [20]

> Те кто включает Strict подлежит презрению коллег.
ну спасибо... ;(
но судя по всему, по их реакции/разговорам на эту тему после очередного глюка, так оно и есть.

← →
tesseract © (2010-04-13 12:16) [21]

> но судя по всему, по их реакции/разговорам на эту тему после
> очередного глюка,

Ессно. Можно же крайнего обнаружить. А так - это всё глючить само!

← →
antonn © (2010-04-13 12:32) [22]

> Скорость разработки обратно пропорциональна времени отладки.
>
> Время отладки составляет 120 % сроков разработки проекта.
>

зависит исключительно от квалификации пишущего

← →
Чупакабра (2010-04-13 12:37) [23]

>Mystic © (13.04.10 10:27) [9] Например,

По Ctrl + mbLeft все тут же становится на свои места.

>положительно, в пхп легкая и быстрая разработка

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

В общем, сравнивнение спринтеров и стайеров.
"Всякий овощ бывает полезен..." (С) Гы

← →
ocean (2010-04-13 12:39) [24]

Думаю, что языки программирования сближаются с естественными, значит типы будут как в VB. Возможно, помогут бандиты:
"Я типа не понял..."

← →
ocean (2010-04-13 12:42) [25]

> "Я типа не понял..."
(имеется в виду void)

← →
Mystic © (2010-04-13 13:03) [26]

> По Ctrl + mbLeft все тут же становится на свои места.

Это уже возможности IDE. Но даже если я увижу, что DecimalSeparator имеет тип Char (или не увижу, если есть только одна DCU), то чем это мне поможет относительно того, что хранится в этой переменной???

Изначально вопрос стоял в том, что появляется вдруг строка $a = $b - $c и неизвестен ее смысл. Ок, попустим я вижу в Delphi строку a := b - c;. Чем это проще? Ок, попустим я даже нашел объявление в некотором модулеa, b, c: Integer. Что это изменит? У нас есть вычитание, а эта операция применима только к числовым типам. Ок, у нас целочисленный тип, а нет действительное число. И?

← →
Чупакабра (2010-04-13 13:19) [27]

> а эта операция применима только к числовым типам.

Перегрузку операторов уже отменили?

>Ок, попустим я вижу в Delphi строку a := b - c;. Чем это проще? Ок, попустим я даже нашел объявление в некотором модулеa, b, c: Integer. Что это изменит?

Картина меняется, если в некотором модуле написано a, b, c: cardinal;

>Это уже возможности IDE. что DecimalSeparator имеет тип Char (или не увижу, если есть только одна DC)

Ок, просто наведи мышку на DecimalSeparator. IDE просто выполняет за тебя поиск, упрощая и ускоряя твою работу. Но, и при отсутствии IDE, тебе не стоит особого труда найти объявление пременной.

>если есть только одна DCU

И ты не знаешь, что там? В общем, как же ты ее тогда умудрился использовать?

← →
Mystic © (2010-04-13 13:42) [28]

> Перегрузку операторов уже отменили?

В PHP ее нет, так что тут можно быть уверенным :)

> Картина меняется, если в некотором модуле написано a, b,
> c: cardinal;

Чуть-чуть меняется, но не кардинально.

Но, и при отсутствии IDE, тебе не стоит особого труда найти объявление пременной.

Точно так же при отсутствии IDE, grep или :vimgrep покажет мне, где используется указанная переменная.

> В общем, как же ты ее тогда умудрился использовать?

А вот код достался по наследству :) Возможно тот, кто писал его, обладат неким эзотерическим знанием, которое было утеряно. В чем, собственно говоря, и вопрос.

← →
DVM © (2010-04-13 13:46) [29]

> Ваше отношение?

осуждаю

← →
antonn © (2010-04-13 13:48) [30]

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

если быдлокодить - то да, и тапочки станут тратуаром, и сапоги батоном хлеба

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

Я что то подобное слышал по отношению к vcl, мол "чистое" winapi учит думать. Ну и вообще в дельфи все просто - кинул кнопку и не думая написал программу. Безмозглые не думающие программисты дельфи...
Пока я вижу лишь комментарии в таком свете.

← →
Чупакабра (2010-04-13 14:29) [31]

2 antonn

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

2 Mystic
>В PHP ее нет, так что тут можно быть уверенным

Мне показалось, или, на самом деле, вопрос был поставлен по-другому?
"Ок, попустим я вижу в Delphi строку a := b - c"

>> Картина меняется, если в некотором модуле написано a, b,
>> c: cardinal;
>Чуть-чуть меняется, но не кардинально.

А давай, чтобы было прозрачнее, будем везде использовать int64? А?

>где используется указанная переменная.

Использование и объявление - разные вещи. Не так ли?

>А вот код достался по наследству :) Возможно тот, кто писал его, обладат неким эзотерическим знанием, которое было утеряно. В чем, собственно говоря, и вопрос.

Какой интересный подход к разработке ПО. Гы. "Не зная брода, не лезь в воду". Вот только, с динамической типизацией, этот "брод" может быть где угодно и чем угодно. А строгая статическая типизация таких неоднозначностей не допускает. Написано "брод" - значит "брод". Иначе - "бред".

← →
oxffff © (2010-04-13 14:39) [32]

Вывод типов и динамическая типизация это разные понятия.

← →
Anatoly Podgoretsky © (2010-04-13 14:48) [33]

> Чупакабра (13.04.2010 14:29:31) [31]

Это фигнявые программисты.

← →
antonn © (2010-04-13 14:55) [34]

> Фигня -она и есть фигня, независимо от того, с использованием
> чего написана.

плохо, когда сам себя уже не понимаешь, да? сочувствую, такая фигня... :(

← →
Игорь Шевченко © (2010-04-13 16:09) [35]

> Я что то подобное слышал по отношению к vcl, мол "чистое"
> winapi учит думать. Ну и вообще в дельфи все просто - кинул
> кнопку и не думая написал программу. Безмозглые не думающие
> программисты дельфи...

В последнее время наметилась одна тенденция. Дело в том, что сейчас для того, чтобы выйти на рынок программных средств и занять в нём свою нишу, фирма, а, соответственно, и программисты должны делать продукт как можно быстрее. При этом, естественно, достаточно часто вопросы эффективности, быстродействия, минимизации размера используемой памяти и тому подобные во внимание просто не принимаются. Зачем, дескать, думать о таких <мелочах>, если современные компьютеры достаточно мощные и <переваривают> почти любые объёмы. Подумаешь, мегабайт памяти туда, мегабайт сюда: Кроме того, очень сильное влияние на квалификацию программистов оказывают многочисленные средства быстрой разработки, бурное развитие которых наблюдается в последнее время. Средства, предназначенные для повышения производительности труда квалифицированных программистов, заняли на рынке совершенно другое место. Достаточно часто эти средства используются программистами низкой квалификации для того, чтобы в кратчайшее время создать работающую программу, прикладывая при этом минимум усилий. Более того, средства быстрой разработки позволяют программисту скрыть недостаток квалификации, ибо вся черновая работа делается без участия программиста. Вместо того, чтобы овладеть необходимым для профессиональной деятельности минимумом, можно недостаток квалификации скрыть посредством использования программы, которая всё сделает сама. Таким образом, средства быстрой разработки используются превратились в средства создания неэффективных программ неквалифицированными программистами. Что поделаешь, рынок диктует свои условия:

Соответственно, такой подход приводит к тому, что достаточно часто у программистов появляется завышенная самооценка. Раз я могу <накропать> программу за неделю, значит, я - ВЕЛИКИЙ ПРОГРАММИСТ, всё умею, всё могу. Зачем мне чему-то учиться, я (при помощи конкретного средства) всегда сделаю то, что хочу! Появилось даже расхожее определение - <программист, пишущий мышкой>: Но стоит у подобных, с позволения сказать, программистов, забрать средство быстрой разработки, как они становятся беспомощными. Ведь они являются программистами на конкретном средстве! Другими словами, они являются ПОЛЬЗОВАТЕЛЯМИ конкретного средства: А пользователи и программисты - это совершенно различные классы людей, использующих компьютер в своей профессиональной деятельности. И если пользователю необходимо знать только порядок использования и взаимодействие частей одной или нескольких программ (WinWord, бухгалтерская или банковская программы, программа обработки изображений и так далее), то программист помимо всего прочего должен, почти обязан понимать то, как функционирует компьютер, на основе каких принципов построена операционная система, понимать принципы организации данных и быть в состоянии написать эффективную программу, решающую поставленную перед программистом задачу. В том случае, если программист является профессионалом, то использование средств быстрой разработки только поможет ему, позволив сократить время, необходимое для разработки программы, и минимизировать усилия, необходимые для разработки таковой.

Непосредственным поводом, подвигнувшим меня на написание этой книги, явился вопрос, заданный в одном из многочисленных форумов по программированию. В этом вопросе, наверное, сосредоточилась квинтэссенция того, о чём я говорил выше. Этот вопрос, судя по всему, был задан именно программистом с явно завышенной самооценкой. Смысл этого вопроса можно свести к следующему. Да, на свете есть хорошие дизассемблеры, в частности, IDA Pro. Но я в ближайшем будущем напишу настолько <крутой> дизассемблер, что IDA Pro моему дизассемблеру и в подмётки годиться не будет. Мне для этого только одной мелочи не хватает. Не будет ли любезен многоуважаемый All сообщить мне смещение в исполняемом файле, с которого необходимо начинать дизассемблирование? Что можно сказать об авторе этого сообщения и его потенциальном продукте?

(http://www.techbook.ru/rumyantsev.html)

← →
tesseract © (2010-04-13 17:19) [36]

> Игорь Шевченко © (13.04.10 16:09) [35]

Седая древность.

← →
TUser © (2010-04-13 19:38) [37]

> Но стоит у подобных, с позволения сказать, программистов,
> забрать средство быстрой разработки, как они становятся
> беспомощными.

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

Но и у них стоит забрать их машину, и уже просто на лошади, как настоящие профи - они не того.

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

Мораль: сложно отрицать более высокую квалификацию тех, кто писал в машкодах, но достаточна ли велика сегодня потребность в таком настоящем программизме?

← →
Игорь Шевченко © (2010-04-13 19:40) [38]

TUser © (13.04.10 19:38) [37]

> но достаточна ли велика сегодня потребность в таком настоящем
> программизме?

Как оцениваем потребность ?

← →
TUser © (2010-04-14 07:45) [39]

По-простецки - через рынок. Среди всего спроса на программистов доля спроса на батонокидателей выше, чем лет 30-50 назад, разве нет? Стало быть доля спроса на профи типа описанного вами, ниже.

← →
test © (2010-04-14 08:28) [40]

TUser © (14.04.10 07:45) [39]
Как объяснить с точки зрения рынка, что по версии книги "Наука отладки" стоимость строчки кода в обычном софте 10 баксов, в НАСА 10000 баксов? В НАСА на первом месте стоит надежность.

← →
12 © (2010-04-14 09:19) [41]

ладно, наверное я несколько не так вопрос ставил.
Однако рад, что нашлись люди думающие как и ваш покорный. :)

Ну и просто
$a = ($b = 4) + 5; // одной строкой а=9 b=4
$a += 5;//а=а+5
$с .= "There!" //с = с+строка
Брр..

где то видал код шахмат в пару кб -
hr687e4956386*&%*$&%$#^*#
oeuiryt4957(&^$(&FKJHO^R*(&E%*(%
- примерно так же выглядит на первый взгляд:
а еще если учесть, что всякие символы $ <? [ используются активно
ровненький квадратик(в браузере, во фрейме смотрел)
творчества рандомного генератора
Как это читать..

← →
antonn © (2010-04-14 09:28) [42]

> Ну и просто

то, что оно позволительно так писать отнюдь не означает что это нужно делать :)
а к конкатенации просто привыкнуть надо

← →
12 © (2010-04-14 09:37) [43]

$i = "W";
for($n=0; $n<6; $n++)
echo ++$i . "\n";
вот честно, напишите что будет выводить и сколько времени вам понадобилось для чтения?

← →
oxffff © (2010-04-14 09:45) [44]

Вопрос не правильно поставлен. Типы есть везде.

Every value generated in a program is associated with a type, either explicitly
or implicitly. In a strongly typed language, the language implementation is required to provide a type checker that ensures that no type errors will occur
at run time. For example, it must check the types of operands in order to
ensure that nonsensical operations, like dividing the integer 5 by the string
“hello”, are not performed. Strongly typed languages may either be dynamically
or statically type checked. Dynamic type checking normally occurs
during program execution, while static type checking occurs prior to program
execution, typically at compile time.1 Other type-related checks may
take place at program link time.
In a dynamically typed language like LISP or Scheme, many operations are
type checked just before they are performed. Thus the code for a plus operation
may have to check the type of its operands just before the addition
is performed. If both operands are integers, then an integer addition is performed.
If both operands are floating point numbers or one is floating point
and the other is an integer, then a floating point addition is performed. However,
if one operand is a string and the other is a floating point number, then
execution is terminated with an error message. In some languages an exception
may be raised, which may either be handled by the program before
resuming normal execution or, if there is no handler or no handler can successfully execute, the program terminates

← →
oxffff © (2010-04-14 09:45) [45]

In a statically typed language, every expression of the language is assigned
a type at compile time. If the type system can ensure that the value of each
expression has a type compatible with the statically assigned type of the expression,
then type checking of most operations can be performed at compile
time, rather than delayed to run time.
Dynamically typed programming languages can be more expressive and
flexible than statically typed languages, because the type checking is postponed
until run time. In general, the problem of determining statically for
an arbitrary program whether a type error will occur at run time is undecidable,
2, yet it is generally accepted that a static type system should be decidable.
As a result, sound static type checkers will rule out some programs as
potentially unsafe that would actually execute without a type error.
While the exclusion of safe programs would seem to be a major problem
with static type checking, there are many advantages to having a statically
type-checked language. These include:

← →
oxffff © (2010-04-14 09:46) [46]

-providing earlier, and usuallymore accurate, information on programmer
errors,
-eliminating the need for run-time type checks that can slow program execution
and increase program size,
-providing documentation on the interfaces of components (e.g., procedures,
functions, and packages or modules), and
-providing extra information that can be used in compiler optimizations.

As a result most modern languages have static type systems.

← →
Игорь Шевченко © (2010-04-14 09:57) [47]

oxffff © (14.04.10 09:45) [44]

Правила читать не ?

← →
oxffff © (2010-04-14 10:14) [48]

> Игорь Шевченко © (14.04.10 09:57) [47]
> oxffff © (14.04.10 09:45) [44]
>
> Правила читать не ?

В разделе рекомендуется.

← →
Mystic © (2010-04-14 12:58) [49]

> Ну и просто
> $a = ($b = 4) + 5;
> $a += 5;
> $с .= "There!";

Это просто непривычности синтаксиа. Вторая и третья строки воспринимаются легко. А в случае первой строки просто не очень удачное использование трюка. Но чем плоха, например, такая запись?

$a = $b = $c = 0;

Или, как в Python

a, b = 9, 4

> вот честно, напишите что будет выводить и сколько времени
> вам понадобилось для чтения?

Ровно столько, чтобы заглянуть в документацию?

← →
Юрий Зотов © (2010-04-14 16:06) [50]

> Язык программирования, где нет типов. Ваше отношение?

Когда после Фортрана и ПЛ/1 (где объявление переменных стандартных типов не является обязательным) перешел на Паскаль, то поначалу жутко раздражала необходимость все объявлять.

Но спустя некоторое время понял, какое это неоценимое благо.

← →
Anatoly Podgoretsky © (2010-04-14 16:10) [51]

Есть программисты, а есть разгильдяи, вот для них подобные языки благо.

← →
Игорь Шевченко © (2010-04-14 16:34) [52]

oxffff © (14.04.10 10:14) [48]

Умеешь все-таки на русском писать.

← →
ProgRAMmer Dimonych © (2010-04-14 20:35) [53]

> [43] 12 © (14.04.10 09:37)
> $i = "W";
> for($n=0; $n<6; $n++)
> echo ++$i . "\n";
> вот честно, напишите что будет выводить и сколько времени
> вам понадобилось для чтения?

А аввтару такого я бы на всякий случай ручонки пообрывал :) Из моего опыта: не стоит рассчитывать, что символы будут иметь определённые коды. Мало ли, веб-программирование в этом плане - штука гадкая :(

> [50] Юрий Зотов © (14.04.10 16:06)
> Когда после Фортрана и ПЛ/1 (где объявление переменных стандартных
> типов не является обязательным) перешел на Паскаль, то поначалу
> жутко раздражала необходимость все объявлять.
>
> Но спустя некоторое время понял, какое это неоценимое благо.

Такое же после Бейсика было. Просто надо из Паскалеподобных языков унаследовать правило о том, что максимум инициализаций в начале функций. Кроме, разве что, временных переменных. Хотя, вообще говоря, достаточно и просто следить за тем, чтобы все переменные были инициализированы.

← →
Eraser © (2010-04-14 21:05) [54]

отсутствие явной типизации в PHP приводит к необходимости довольно часто приводить значения с пом. функций вроде intval, strval и т.д.

← →
Я всегда говорил! (2010-04-14 22:42) [55]

> TUser © (13.04.10 09:54) [2]
>
> Нестрогая типизация - хорошо для небольших программ, скртипты
> там всякие. Список языков какой-то странный, писал бы уж
> - Perl, JavaScript :-)

А 1C?

← →
test © (2010-04-14 23:03) [56]

Я всегда говорил! (14.04.10 22:42) [55]
А Python?

← →
antonn © (2010-04-14 23:06) [57]

> 12 © (14.04.10 09:37) [43]
>
> $i = "W";
> for($n=0; $n<6; $n++)
> echo ++$i . "\n";
> вот честно, напишите что будет выводить и сколько времени
> вам понадобилось для чтения?

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

← →
Я всегда говорил! (2010-04-14 23:31) [58]

> test © (14.04.10 23:03) [56]

Я бы не назвал программы на 1С небольшими.

← →
ProgRAMmer Dimonych © (2010-04-15 02:21) [59]

> [54] Eraser © (14.04.10 21:05)
> отсутствие явной типизации в PHP приводит к необходимости
> довольно часто приводить значения с пом. функций вроде intval,
> strval и т.д.

strval() никогда не нужен был лично мне. Потому как при использовании в строковых выражениях он и так строкой станет, своего рода основной тип в PHP (что вполне закономерно, если учесть область применения языка). А intval() требуется лишь тогда, когда хочется отправить запрос к БД, защититься от SQL-инъекций и при этом не использовать подготовленные выражения. Ну, чуть реже, - чтобы быть уверенным, что мне именно число передали в скрипт, а не чёрт знает что. Если есть 100%-ная гарантия, что там всегда будет корректное числовое нечто, то и intval() не нужен: знай плюсуй себе, сколько душе угодно.

← →
Eraser © (2010-04-15 03:24) [60]

> [59] ProgRAMmer Dimonych © (15.04.10 02:21)

> Ну, чуть реже, - чтобы быть уверенным, что мне именно число
> передали в скрипт, а не чёрт знает что. Если есть 100%-ная
> гарантия, что там всегда будет корректное числовое нечто,
> то и intval() не нужен: знай плюсуй себе, сколько душе
> угодно.

php он в связке с веб-сервером работает в 99% случаев, а там все входные параметра априори не заслуживают доверия.
тут дело в том, что никто 100% гарантии не даст, что в такую то функцию передаются 100% верные параметры, тем более, что практически все действия тем или иным способом сводятся к обращению к БД, либо выводу информации в html. т.о. правилом хорошего тона является не доверие к параметрам методов (всех методов и всех параметров), соответственно нужно явно приводить + строки обрабатывать дополнительными спец. функциями для предотвращения инъекций из них же.

← →
test © (2010-04-15 07:01) [61]

Я всегда говорил! (14.04.10 23:31) [58]
Python представляет такую свободу обращения с данными что VB, PHP, 1С и не снилась. На нем уже написано много чего. 1С встроенный язык и облегченный чтобы все кто угодно могли на нем писать, в принципе идеология у него скопирована с Бейсика, синтаксис с Паскаля. Как ты хотел сравнивать проблемно ориентированный язык и универсальные?

← →
ProgRAMmer Dimonych © (2010-04-15 15:36) [62]

> [60] Eraser © (15.04.10 03:24)
И правильно. Но если данные идут в БД - тут, конечно, intval, о чём я и писал в [59]. В HTML же данные обычно идут строковые. Причём если они попали в скрипт только что из $_GET[] или $_POST[] и им подобных - то имеем полное право сделать минимальную проверку корректности. Ибо за остальное в ответе отправитель (а может он ломать нас пытается). Если же данные в HTML помещаются по итогам выборки из БД, то строками они и помещаются. Фильтрация "число/не число" - это ещё при добавлении, дабы базу не засорять, а подготовку к отображению на выходе - ну так тут сам Бог велел пропустить через пару-другую функций, чтобы гарантировать, что всё корректно отобразится.

Это я всё к тому, что (по крайней мере, по моему опыту) в PHP 2 основных типа: числа и строки - почти как в Бейсике времён нашей молодости. Массивы и всё остальное - отдельно, ибо составные. Соответственно определять тип явным образом приходится только для того, чтобы быть уверенным, что на месте числа - число. Т.е. intval() - да, для валидации данных приходится использовать. Но в строго типизированных тоже бы так делали: из строки - в число. А strval()... Разве что массив подсунут. Но там, где ждём массива - это можно обработать сразу с разбором оного, а где не ждём - это значит нам подсунули некорректные входные параметры. И, соответственно, имеем полное право отображать "Array()" вместо текста, ибо нефиг :)

← →
tesseract © (2010-04-15 16:13) [63]

> в принципе идеология у него скопирована с Бейсика, синтаксис
> с Паскаля.

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

В 1С "свобода" типизации ограничена только базовыми типами. В 8 типизацию сильно приструнили.

← →
Eraser © (2010-04-15 17:35) [64]

> [62] ProgRAMmer Dimonych © (15.04.10 15:36)

> Но в строго типизированных тоже бы так делали: из строки
> - в число.

так то оно так, но только 1 раз, при получении данных из вне, а далее в методах уже типизированные аргументы, туда вместо числа строку не подсунешь. таких вложенных методов может не один десяток вызываться, а то и сотня за время выполнения скрипта, т.о. если заглянуть в профилировщик, то на контроль типов в php уходит не малая часть ресурсов.

← →
tesseract © (2010-04-15 17:59) [65]

> то на контроль типов в php уходит не малая часть ресурсов.

Всегда считал, что типизация происходит по факту. Внутренним вызовом функции приведения и/или хранением значения по многим типам.

← →
Кто б сомневался © (2010-04-15 18:13) [66]

Отрицательное. Сделать ошибку в таком языке намного проще, и больше времени потратишь на ее поиск. Это реально отнимает кучу времени. Это на примере php. В Delphi я б и не допустил ошибок.
И код сложнее и медленнее читать.

php :

$yep = array("раз", true);
$nein = array("раз", "два");

if ($yep == $nein) echo "Два массива равны" - код прокатит и массивы равны.

или

$zero = 0;
$tss = "";

if $zero == $tss echo "Переменные равны"

Если туда поставить 10 и "10" - последнее в виде строки то тоже будут равны.
На этом фоне я уже сделал одну ошибку, и долго ее искал хотя знаю про оператор ===.

Если сделать так:

$ten = 10;
if ($ten == true) echo "Равны" - тоже прокатит.

← →
test © (2010-04-15 18:20) [67]

tesseract © (15.04.10 16:13) [63]
Про свободу это я про Python.

Про 1С, странно мне казалось что гибрид от туда.

← →
antonn © (2010-04-15 22:53) [68]

> Но если данные идут в БД - тут, конечно, intval, о чём я
> и писал в [59].

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

>
> $yep = array("раз", true);
> $nein = array("раз", "два");
>
> if ($yep == $nein) echo "Два массива равны" - код прокатит
> и массивы равны.

а может array_diff()? :)

> На этом фоне я уже сделал одну ошибку, и долго ее искал
> хотя знаю про оператор ===.

ну и чтож теперь? в справке написано об этом, использование - дело привычки

← →
ProgRAMmer Dimonych © (2010-04-16 00:28) [69]

> [64] Eraser © (15.04.10 17:35)
В том-то и фишка, что можно не различать, строка или число. Главное - чтобы это значение было корректным при попытке привести к числу. Этого и достигаем через intval() Единожды при поступлении. Остальное разработчики PHP очень и очень неплохо заоптимизировали. И мы из PHP уж точно не сделаем это быстрее.

> [66] Кто б сомневался © (15.04.10 18:13)
Интересно, а зачем такой цирк понадобилось устраивать? Что за задача-то была? Тот же "логический тип" лично мне приходилось использовать разве что при анализе значения, возвращаемого strpos() и ей подобными, ибо у них символы в строке с нуля, а если не найдена подстрока - то FALSE. Но тоже проверка единожды, сразу по факту.

> $ten = 10;
> if ($ten == true) echo "Равны" - тоже прокатит.

Ну так и такое в старом-добром Си прокатит:

ten = 10; if (ten) printf("Aha!");

И никакого сравнения с true не надо. Программирование - это игра по правилам. Которые придумывает кто-то другой. Пока эти правила подробно расписаны и более или менее стройно согласованы, писать на соответствующем языке - сплошное удовольствие.

> [68] antonn © (15.04.10 22:53)
> это неверный подход.
> Для защиты от иньекций применяются специальные функции для
> этого предназначенные, например mysql_real_escape_string()

Сие уже семимильными шагами уходит в небытие. Подготовленные выражения куда мощнее и надёжнее.

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

intval() вернёт вполне конкретное значение для не-числового аргумента - 0. Более чем достаточно для большинства задач. На крайний-то случай можно нечто такое:

if (intval($SomeVar) != $SomeVar) ... // Error occured!

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

> [69] ProgRAMmer Dimonych © (16.04.10 00:28)

> Единожды при поступлении.

кто это "единожды" определять будет в проекте под миллион строк кода, где примеру только модуль маназина почти на 20 МБ?
велосипеды изобретать не имеет смысла, есть стандарты дефакто разработки для php (достаточно взглянуть на исходники какой нибудь известной CMS) и пара-тройка хороших книг.

> [70] Eraser © (16.04.10 01:22)

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

Если же приходится по чьему-то пожеланию свыше явно указывать типы параметров для методов классов (вроде это имелось в виду?), то, видимо, придётся играть по этим правилам вопреки задумке языка. Но реально обработки на входе достаточно. Можно громоздить сколько угодно сущностей всех мастей, но в итоге всегда всё сведётся к 3-м: 1) браузер, 2) скрипт и 3) хранилище данных. Из них только для скрипта есть разница, какой смысл (тип) имеют те или иные данные. Потому что для хранилища это просто поток информации (плюс-минус структурированные, но всё равно "просто данные"), а для браузера - всё строка. М.б. упрощаю?

>
> intval() вернёт вполне конкретное значение для не-числового
> аргумента - 0. Более чем достаточно для большинства задач.
> На крайний-то случай можно нечто такое:

Неужели не ясно, что если в запрос передано "Mama" вместо "159" то этот запрос некорректный? и приведя к типу мы получим "0", запрос выполнится с некорректными данными. Потому что переданый "Mama" не является ожидаемым числом 159, так же как ноль не является числом 159.
Ты специально изменяешь входные данные так, чтобы они прошли в запрос. Проверка на соответствие типу и изменение данных для соответствия типу - разные вещи, и твой подход это не "защита", это большой костыль и потенциальная головная боль в будущем при отладке и использовании

> Сие уже семимильными шагами уходит в небытие. Подготовленные
> выражения куда мощнее и надёжнее.

чем?
а если прикинуть - а вдруг bind_* внутри себя сам вызывает ескейпинг?
вооще множество дырок появляются потому что "вот тут должно быть число, а значить ескейпить не надо", простое правило "ескейпим любые данные" позволит сохранить кучу нервов

> [72] antonn © (16.04.10 13:46)
> > intval() вернёт вполне конкретное значение для не-числового
> > аргумента - 0. Более чем достаточно для большинства задач.
> > На крайний-то случай можно нечто такое:
> Неужели не ясно, что если в запрос передано "Mama" вместо
> "159" то этот запрос некорректный? и приведя к типу мы получим
> "0", запрос выполнится с некорректными данными. Потому что
> переданый "Mama" не является ожидаемым числом 159, так же
> как ноль не является числом 159.

А дальше было такое: if (intval($SomeVar) != $SomeVar) ... // Error handling

Никто не заставляет обязательно приводить к целому. Но если ждём целого - мы его всё равно захотим увидеть. А в ряде задач, кстати, ообенно если готовые функции уже есть, возвращаемое нулевое значение - то, что надо, при ошибках-то. Как NULL в параметрах к WinAPI-функциям.

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

Где это было написано? Там дальше шёл кусок кода, я его уже повторил. Идея: приведение использовать, чтобы отследить некорректность данных. Никто не заставляет обязательно использовать _результат_ приведения. Проверка через приведение и для корректных данных работаем, как душе угодно. Хотя, если говорить конкретно о запросах к БД, то и здесь иногда вполне устраивает вариант с нулём. От задачи.

> чем?
> а если прикинуть - а вдруг bind_* внутри себя сам вызывает
> ескейпинг?

Вот как раз-таки, когда ескейпинг делается автоматически, то ошибок на-а-амного меньше. Да и вряд ли он ескейпит: запрос-то уже отправлен, что делать с данными известно. Зачем ескейпить, если в запрос их подставлять уже не нужно, а только тупо использовать. Например, сбросить "как есть". Escape-последовательности - они имеют смысл только когда в тексте запроса сами данные. И, кстати, с этой точки зрения подготовленные выражения очень хороши для отделения логики от данных. Этакий кусочек MVC там, где его вроде как и не ждали :)

> вооще множество дырок появляются потому что "вот тут должно
> быть число, а значить ескейпить не надо", простое правило
> "ескейпим любые данные" позволит сохранить кучу нервов

Да ну?

В строго типизированных было бы точно так же, только ещё жёстче. А нервов сэкономить... Хм... И хранить, видимо, две копии данных: одну - для вставки в запросы, вторую - для обработки скриптом? Так это свечи-о в аптеке... Или ескейпить только перед самым запросом? И радоваться, когда случайно пропущенный real_escape_string поможет "доброжелателям" населить сайт хомячками и виагрой.

Отследить корректность входных данных - это 2-3 выполненных строки в начале скрипта (или функции, которая обрабатывает конкретный запрос к нему). Если получается больше - пора задуматься о структурировании и разбиении на модули. А после того, как данные гарантированно корректные, разделение на числа и строки уже в самом коде и первый параметр bind_param() это помогает подчеркнуть. Да и, думается, на скорости выполнения запроса сервером БД положительно скажется.

В конце концов: не дураки же подготовленные выражения придумали? С ними спать спокойнее стало намного. И ведь они, as far as I remember, поддерживаться мускулом стали раньше, чем в PHP появилось расширение MySQLi, что, кстати, вполне закономерно. Следовательно bind_param() всего лишь отправляет данные. А если дыры и будут - то в самом мускуле, а уж его-то фиксят как положено.

> А intval() требуется лишь тогда, когда хочется отправить
> запрос к БД, защититься от SQL-инъекций и при этом не использовать
> подготовленные выражения.

> [74] antonn © (16.04.10 15:15)
> > А intval() требуется лишь тогда, когда хочется отправить
> > запрос к БД, защититься от SQL-инъекций и при этом не
> > использовать подготовленные выражения.

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

Вот еще один момент, из за которого потерял пол часа.

// много кода

$pub_key=fread($fp, 8192);

// много кода

openssl_public_encrypt($plaintext, $encrypted, $pubkey);

Никак не мог понять почему ключ is not valid public key .
А в Delphi я бы сразу при компиляции исправил подобную мелочь.

$pub_key
Причина в том, что в коде
openssl_public_encrypt($plaintext, $encrypted, $pubkey);

Создается втихую новая переменная pubkey вместо pub_key

> [77] Кто б сомневался © (17.04.10 03:44)
Причина в том, что язык интерпретируемый, а не в том, что "без типов". И спасёт здесь только единый подход к именованию переменных, IMHO. Например, если нижнее подчёркивание - то после каждого слова. Или сплошным текстом. Или Camel-style. Согласитесь, если после $pub_key у Вас руки потянулись к $pubkey, то проблема в непривычности одного из вариантов написания?

ProgRAMmer Dimonych © (17.04.10 04:19) [78]

Неа. Ты не прав 2 раза.
Во первых причем здесь "язык интерпретируемый"? Все зависит от конечного парсера и проверки на корректность кода.
Во вторых это как раз зависимость от типов. Т.к. если в языке есть тип, то мне пришлось бы сначала объявить эту переменную (неважно где), в языке где нет типов можно создавать переменные "находу". Это прямое "последствие" этого подхода.

> Кто б сомневался (17.04.2010 13:59:19) [79]

Создание переменных на ходу требует интерпритируемости.

> Создание переменных на ходу требует интерпритируемости.

Ничто не мешало разработчикам создать проверку кода на подобные ошибки. Мол переменная не используется но объявлена. Это сильно упростило бы отладку.

> Ничто не мешало разработчикам создать проверку кода на подобные ошибки.

tesseract © (13.04.10 11:20) [12]
>> sniknik © (13.04.10 11:12) [11]
>> вообще из-за необязательности объявления переменных

> В PHP вроде можно Strict включить ? Очень полезная вещь.

> Кто б сомневался (17.04.2010 14:23:21) [81]

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

> niknik © (17.04.10 14:29) [82]
>

Strict mode is only on PHP4. PHP5 has something called Safe Mode.

Включил вроде помогло, E_ALL | E_STRICT или в phpED - error level 4 - выбрасывает месседж.

> Anatoly Podgoretsky © (17.04.10 14:41) [83]

Сейчас php так и работает. "Интерпретатор и в ран тайм определяет тип переменной по контенту"

А это все к твоей фразе

> Во первых причем здесь "язык интерпретируемый

Не во первых, а поскольку, не инпретирующие не могут делать это в рантайм, поскольку для этого им надо стать интерпретируемым.

> Anatoly Podgoretsky © (17.04.10 14:57) [86]

Я имел ввиду в 79 что в данном случае суть в инструментах для отладки (что там и написал). Если бы была возможность проверить подобные вещи до запуска скрипта - это сэкономило бы массу времени.

> Т.к. если в языке есть тип, то мне пришлось бы сначала объявить
> эту переменную (неважно где), в языке где нет типов можно
> создавать переменные "находу". Это прямое "последствие"
> этого подхода.

Может быть, мне и приснилось, но, кажется, в C++ можно было объявлять чуть ли не в любом блоке кода новые переменные? for (int i=...) Не Паскалем единым маются программисты.

PHP отличный язык, че бочку катите?? ))) Автор, если он тебе не нравится, то ты просто не умеешь его готовить :) Либо исходники кривые

ЗЫ: Всегда использую safe mode и вывод всех привсех хинтов и ошибок.

> PHP отличный язык, че бочку катите?? )

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

> А в Delphi я бы сразу при компиляции исправил подобную мелочь.

1C таки на этапе сохранения отлавливает подобное. Не смотря на то, что интерпретируемый.

> [91] Кто б сомневался © (19.04.10 14:30)
> Я честно говоря до последнего не верил что в php нельзя
> работать со структурами.. Нет там такого просто.

Ассоциативный массив - вот какая штука. Это оно и есть. Немного другое синтаксически, физически. Но логически - то же самое. Fine Manual is somewhere nearby. ;)

> Немного другое синтаксически, физически. Но логически -
> то же самое.

Это хэш из перла, не совсем ассоциативный массив. Таки ПХП первых версий был перловкой.

> Это хэш из перла, не совсем ассоциативный массив. Таки ПХП
> первых версий был перловкой.

В подробности не вдавался. Когда начинал с PHP возиться - уже 4-я версия была повсюду. И в доках "ассоциативный массив" называлось. Главное - что оно работает и успешно заменяет. ;)

> Ассоциативный массив - вот какая штука. Это оно и есть.
> Немного другое синтаксически, физически. Но логически -
> то же самое. Fine Manual is somewhere nearby. ;)

Не заменяет она структур. Мне нужно было сделать файл структурный бинарный, чтобы его можно было читать и с php и с exe. А вот хрен.

> [96] Кто б сомневался © (19.04.10 23:10)
> Не заменяет она структур. Мне нужно было сделать файл структурный
> бинарный, чтобы его можно было читать и с php и с exe. А
> вот хрен.

Никогда не было нужно. Но, насколько не подводит память, implode() бинарно-безопасна. Значит, используем ассоциативный массив, а потом implode"им и выбрасываем в файл. При чтении - на chunk"и бить, там тоже функции есть. Как же это делали разработчики расширений для управления ZIP, PDF, Flash, MP3, той же GD разработчики. Было бы желание :)

> ProgRAMmer Dimonych © (19.04.10 23:51) [97]

Толку то, все равно в итоге текст будет.
Значит делали по другому. Так же как встроена openssl (набор функций которые незаметно работаю с exe openssl).

> Как же это делали разработчики расширений для

Делали в виде расширений ( extensions - набор dll).

Язык программирования, где нет типов. Ваше отношение? Найти похожие ветки