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

← →
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()? :)

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

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

> [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]

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

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