Молодые языки. Куда катится программирование?

[Reflector]

Приведенная программа не обеспечивает выполнение условия.

Какого условия? Смотря на тот исходник можно вполне однозначно сказать что будет напечатано, это и есть соответствие исходника результату исполнения. Если сам результат, допустим функции rand(), даже берущей случайное число из астрала, заранее определить невозможно, то соответствие никуда не пропадает, т.к. ты узнаешь о таком результате(а не самом результате!!!) глядя на исходник, а не пишешь одно, а после запуска получаешь совершенно другое... Это понятно? Именно поэтому нормальные люди набирая "С-тексты" говорят что пишут программу, хотя "С-тексты" явно не выполняются...

[homo ludens]

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

Не при каждом. Реально меняется очень редко, на некоторых СУБД не меняется вообще. Зависит от механизмов хранения и того, что делали с базой между вызовами. Но - меняется.
На больших объемах данных и на таблицах хранящихся как хеши - будет разным на разных СУБД. С одними и теми же данными.

Так что определение "однозначное соответствие между исходником + входными данными и результатом выполнения" уже не катит. Может модель СУБД добавить?

Еще как обеспечивает. Ты похоже не в курсе что числа там _псевдо_случайные, а rand() это обычная математическая функция.

Ты похоже не в курсе, но детально функция rand в POSIX не специфицирована, потому даже на одном компиляторе и даже на одной либе и даже с одним seed, но на разных платформах у тебя будут разные результаты.

Так что определение "однозначное соответствие между исходником + входными данными и результатом выполнения" уже не катит. Может платформу добавить?

а шо, там по стандарту требуется какой-то порядок сортировки?

Не специфицирован, потому может быть любым. На практике - см. ответ выше.

Какого условия? Смотря на тот исходник можно вполне однозначно сказать что будет напечатано, это и есть соответствие исходника результату исполнения.

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

Если сам результат, допустим функции rand(), даже берущей случайное число из астрала, заранее определить невозможно, то соответствие никуда не пропадает, т.к. ты узнаешь о таком результате(а не самом результате!!!) глядя на исходник, а не пишешь одно, а после запуска получаешь совершенно другое... Это понятно?

А с HTML все принципиально не так и соответствия там никакого нет?
И я могу написать <b>hello wolrd!</b> а получить <i>fuck off!</i>?

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

Нормальные люди перед практикой программирования изучают теорию. Важной частью которой является машина Тьюринга. И в процессе изучения вопрос "данные или программа" исчезает сам собой.

[Strannik-au]

Не при каждом. Реально меняется очень редко, на некоторых СУБД не меняется вообще. Зависит от механизмов хранения и того, что делали с базой между вызовами. Но - меняется.
На больших объемах данных и на таблицах хранящихся как хеши - будет разным на разных СУБД. С одними и теми же данными.

Так что определение "однозначное соответствие между исходником + входными данными и результатом выполнения" уже не катит. Может модель СУБД добавить?

Ты меня конечно извини но в таком случае это уже будут другие данные.

Нормальные люди перед практикой программирования изучают теорию. Важной частью которой является машина Тьюринга. И в процессе изучения вопрос "данные или программа" исчезает сам собой.

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

[homo ludens]

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

Удачи, господа.

[Kirax]

даже на одном компиляторе и даже на одной либе и даже с одним seed, но на разных платформах у тебя будут разные результаты.

Я пожалуй соглашусь с Reflector-ом. В стандарте написано "любое число в определенном промежутке" - ты его и получаешь.

Не специфицирован, потому может быть любым. На практике - см. ответ выше.

Опять же - порядок не специфицирован, значит это не может считаться "неопределенностью" результата. То есть "порядок" в данном случае не входит в понятие "результат".

А с HTML все принципиально не так и соответствия там никакого нет?
И я могу написать <b>hello wolrd!</b> а получить <i>fuck off!</i>?

В текстовом режиме разницы между <b> и <i> действительно нет. Впрочем если ты и простой текст считаешь программой...

Нормальные люди перед практикой программирования изучают теорию. Важной частью которой является машина Тьюринга. И в процессе изучения вопрос "данные или программа" исчезает сам собой.

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

[Kirax]

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

Ты кажется только что говорил про машину Тьюринга? Можешь привести пример недетерминированной программы для машины Тьюринга?

[ZSunny]

Достаточно интересное обсуждение, и поэтому я не хотел вставлять свои пять копеек (it will be fun while it lasts (с) bash.org), но они такие: давать формальное определение языка программирования ненамного интереснее, чем давать формальное определение кошки. Понятие формального языка (алфавит, множество строк над алфавитом, язык как некоторое его подмножество) абсолютно справедливо называет языком множество всевозможных рецептов приготовления курицы. Попытка формализовать интуитивное понятие языка программирования, отталкиваясь от каких-то существующих примеров - во-первых, зело тяжела, судя по предыдущему флейму, во-вторых, лично мне кажется, что в ней нет особого смысла. Разве что для французской палаты мер, весов и языков, которая сможет развешивать ярлычки: "это таки язык программирования", "нет, ше ви, это ни разу не язык программирования"
Я хотел бы предложить вернуться к первоначальной теме ("Куда катится программирование"), если нет возражений.

[Reflector]

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

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

[homo ludens]

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

ППКС

skip

skip

skip

Мы уже и так тему зафлудили, если есть время и желание флеймить дальше - давай делать новую тему.

Хотя, повторюсь,

Это вопрос чисто терминологический и споры о том, что HTML не является языком программирования до тех пор, пока в нем не появляется <? echo ?> - считаю софистикой.

[ZSunny]

Кстати, нашел одну интересную цитату в книге "Параллельные вычисления" Воеводиных:

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

Так что, исходя из этого прецедента, русский язык следовало бы отнести к языкам программирования
О развитии языков программирования. Мое IMHO: последние (достаточно много) лет императивные языки программирования общего назначения развиваются по направлению ограничения возможностей программиста. Отказ от go to, структурное программирование, понятие инкапсуляции в ООП, принцип сокрытия информации (хотя он и вводился первоначально как средство, при помощи которого можно было бы скрыть то, что может потом поменяться), виртуальные машины. Все эти отказы делались с целью получения каких-то выгод. Во-первых, это была борьба с растущей сложностью программ, во-вторых - "мечта о компиляторе" или "мечта о низком уровне": "а давайте бы будем писать на языке программирования среднего/высокого уровня правильные программы, не задумываясь об особенностях конкретного компьютера, а компилятор будет делать из них эффективные".
Думаю, эта тенденция сохранится еще на долгие годы. Во-первых, в императивные языки общего назначения будут вноситься отдельные элементы функционального подходя. Сейчас уже есть примеры подобных объединений: Т-система (функциональный подход на верхнем уровне, императивный - на нижнем), отчасти - EJB (который не имеет никакого отношения к императивному подходу, но бины можно считать "чистыми исполнителями", которые отказываются от взаимодействия с другими бинами в обход установленных правил). Скорее всего, это будет только внесение элементов функционального подхода, но полностью переход к функциональному подходу не произойдет: у меня нет существенного опыта работы с функциональными языками программирования, чтобы делать подобные заявления, но по описанию LISP-а и небольшому опыту в PROLOG-е (пусть не функциональный язык, но все-таки) сложилось впечатление, что "чистые функции" - это хорошо в теории, но как только дело доходит до практики, тут же появляется "база данных" и прочие костыли, которые и мешают системе выполнения, и ставят вопрос "а зачем тогда было начинать?"
Во-вторых, по мере роста сложности программ все четче видна проблема верификации. Формальные модели семантики - слишком сложно, модульное тестирование и тестирование черного ящика - не дают 100% гарантии. Кроме того, для формальной верификации нужна достаточно подробная формальная спецификация. На данный момент, если я не ошибаюсь, не существует адекватных средств для превращения формальной спецификации в программу (поскольку остается вопрос эффективности, который в спецификации записать сложно, а сказать компьютеру "максимизируй" - боюсь, не справится), но развитие, скорее всего, пойдет именно в таком направлении: задача программиста превратится из создания программ в доведение спецификаций до такого состояния, когда компьютер сможет написать программу сам. Хотя, конечно, тут вылезет закон дырявых абстракций, как же без него
В-третьих, сейчас программирование - это написание очередного модуля системы из предположения, что все остальные работают правильно, а некорректные данные могут исходить только из внешних по отношению к системе источников, а поскольку все взаимодействие с такими источниками происходит в специфичных модулях, которые получают информацию и валидируют ее - внутри системы передаются только корректные данные. Аналогично и отладка всегда производится как поиск одной ошибки при предположении, что все, кроме этой одной ошибки, работает правильно. Это хорошо для маленьких программ, но плохо для больших. Поэтому вместе с элементами функционального подхода, которые будут как-то связаны с традицией разбиения большой системы на подсистемы с четко регламентированными связями, будут вводиться какие-то средства контроля потоков данных и выполнения. Что это будет - не имею даже малейшего представления, но это будет точно.
Что вы скажете на это IMHO?

[shipr]

прошу не кидать в меня ничего тяжёлого. Всё нижеописанное имхо.
На днях мельком посмотрел язык программирования Groovy. Первое что бросилось в глаза (в отличие от оригинальной джавы), это отсутствие интерфейсов как таковых.
оригинальная джава

Object vatiable = new Object();

Груви

def variable = new Object();

т.е. переменная variable является переменной неопределённого типа, т.е. по сути там непонятно что там есть - объект или значение (примитивные типы int, long, char). Такое же безобразие я видел в php и javascript.
Хотел бы подискутировать на тему хорошо это или плохо.
С одной стороны это хорошо (убираются рамки, какой хочу метод такой запускаю), с другой стороны прощай ООП?

[korbus]

В третьем шарпе есть похожая фишка, называется "неявное указание типа переменной". Т.е. тип переменной компилятор выводит сам, исходя из типа выражения. По поводу неопределенности - здесь тип всегда определен, просто его можно не указывать, компилятор поймет что вы имели в виду.

[Strannik-au]

т.е. переменная variable является переменной неопределённого типа, т.е. по сути там непонятно что там есть - объект или значение (примитивные типы int, long, char). Такое же безобразие я видел в php и javascript.
Хотел бы подискутировать на тему хорошо это или плохо.
С одной стороны это хорошо (убираются рамки, какой хочу метод такой запускаю), с другой стороны прощай ООП?

Почему прощай ООП?
Вон у вас обьект никуда не делся.

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

[shipr]

Груви - это надстройка над jvm , альтернатива сановской jdk, и джава и груви крутятся под одной и той же jvm, генерят один и тот же байткод, просто синтаксически отличаются (хоть и немного).
скорее всего я неточно выразился по поводу неопределённых типов. Меня интересует зачем придумали не указывать тип переменной/объекта. Что нам это даёт, кроме путаницы и ексепшенов. Я считаю что это не есть хорошо, т.к. многие ошибки могут быть не отловлены на этапе компиляции. С другой стороны это упрощение совсем не упрощает жизнь (сори за каламбур).

ЗЫ кстати, про generic's (wild cards) можно(нужно) забыть получается....
ЗЫЫ объекты передаются ссылками, примитивные (char, byte, long,int,float,double) передаются значениями

[Strannik-au]

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

public interface Test {

}

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

[Odalex]

MathML
The principal goal of MathML is to enable mathematics to be served, received, and processed on the Web, just as HTML has enabled this functionality for text.

этим рисуем формулу любой сложности, а с помощью xslt можно написать макрос который будет считать результат

это для тех кто говорит что markup language это не язык программирования))

[Strannik-au]

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

[Reflector]

MathML
The principal goal of MathML is to enable mathematics to be served, received, and processed on the Web, just as HTML has enabled this functionality for text.

этим рисуем формулу любой сложности, а с помощью xslt можно написать макрос который будет считать результат

это для тех кто говорит что markup language это не язык программирования))

Так это MathML у нас markup language, а xslt является декларативным языком программирования

[MAxZ]

речь о языке разметки и языке программирования:

Приведи формальный алгоритм, который отличит их друг от друга.

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

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

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

не любил я теорию трансляции, правда по большей части из-за того КАК нам её преподавали... но имхо язык программирования - это язык разметки + интерпретатор/компилятор (семантика). потому определить есть ли семантика за данной разметкой - это задача на уровне "понять смысл предмета по его форме".

[MAxZ]

споры о том, что HTML не является языком программирования до тех пор, пока в нем не появляется <? echo ?> - считаю софистикой.

эээ... а что это за инструкция <? echo ?> ?
кажеца в HTML такое оццуцтвует? или есть? лень искать, насколько я помню это инструкция для РНР или подобного языка, вставляемого внутрь выдаваемой HTML.