Pull to refresh

Comments 47

Наверное, они подразумевают #1 и гордятся этим :)
UFO just landed and posted this here
Просто эволюция
с
с++
с# = c++++
А — есть, B — есть, С — есть, D — есть, E — вроде нету, F — будет.
Прикол какой-то.
интересно, а что будет после F#?..
переход на новый уровень: 10#? :)
Кстати, может быть они хотят собрать коллекцию
A#, C#, D#, F#, G#?
И наконец-то научиться играть на гитаре! (:
а следующая будет редакция Brainfuck B#add+7 (это аккорд такой) =)
пусть уже дойдут до Z# и успокоятся что ли...
UFO just landed and posted this here
UFO just landed and posted this here
C хаскеля там вроде бы вобще-то ничего не слизано, это ocaml в чистом виде
Да и от окемла он ушел уже довольно далеко, кстати. И с каждой новой версией все дальше.
Тратить то легко, скармливать купюропрёмникам не очень приятно.
Ага, потом PHP# (с огрооомным фреймворком), потом Ruby## ("Hi, I'm php sharp! Hi, and I'm Ruby on Sharps!")... затем последуют asm# (управляемый машинный код, тормоза на новом уровне!) и Perl#.

Вообще радует, что можно точно увидеть, продвигается ли какой язык Майкрософтом.
UFO just landed and posted this here
Мне вот хотелось бы отличия от IronPython увидеть. Оный тоже функцианальный и под .NET.
IronPython — это реализация языка Python для .NET. Python — ни разу не функциональный язык. Там даже лямбд нормальных нет, а то что есть, грозятся выкинуть (а может, уже выкинули, я не слежу). Python — язык с динамической типизацией, F# со статической типизацией.

Достаточно?
Заметил в своем комментарии синтаксическую ошибку - я не специально.
Может еще я и не совсем корректно выразился. Python ведь поддерживает ФП? Может он не совсем функциональный в корне. Стало-быть выбор за разработчиком - какой парадигмой пользоваться. И называть ли его функциональным языком. Верно?
Мне интересно, я пока только изучающий Python.
Можно и на C в объектном стиле писать (см. GTK), и на ассемблере, но объектным они от этого не становятся.
О Python можно сказать, что он поддерживает элементы функционального программирования?
Ну если вам так хочется — пожалуйста :)
Питон разве функциональный?
А, почитал википедию. Да, примерно настолько же функциональный, как JavaScript. Может чуть лучше :). Руби тогда тоже функциональный. Если фа-диез действительно функциональный, то отличий от железного питона будет ну очень много. :)
Хм. Перечитаю про парадигмы и Python.
Пока источниками для меня были: про парадигмы и про Python.
Я большой поклонник языков функционального программирования, особенно Lisp-а. Надеюсь, в M$ не напортачат как обычно, и скоро можно будет поработать с современным языком функционального программирования.

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

Мне кажется, тут ошибка. Есть три вида языков программирования: императивные, функциональные и логические (ну да, ООП ещё есть:)). Первые два указывают на последовательность решения задачи и только ЛОГИЧЕСКИЕ языки (такие как пролог) "описывают как решить задачу, но не предписывают последовательность действий". Более того, только в логических языках: "система реализации языка должна сама выбрать нужный порядок выполнения команд, который приведет к желаемому результату...". Короче, Вы тута перепутали логические и функциональные языки.
И как же в функциональных языках указывается последовательность?

Теорему Чёрча-Россера знаете?
Я исхожу из того, что написано в: Роберт В Себеста, Основные концепции языков программирования. Теорему такую, увы не знаю.
Почувствуйте разницу:
"Программирование как на императивных, так и на функциональных языках в основном является процедурным. Это означает, что программист знает, что именно должно быть выполнено программой, и указывает компьютеру, как именно следует выполнять вычисления. Программирование на некоторых неимперативных языках и, в частности, на языках логического программирования, является непроцедурным. Программы на таких языках не содержат указаний как именно вычислить результат, а только описывает форму результата. Отличие состоит в том, что мы предполагаем, будто компьютерная система может каким-то образом определить, как именно должен быть получен результат."
Проще говоря, в выражении из статьи "тексты программ на функциональных языках программирования описывают как решить задачу, но не предписывают последовательность действий для её решения" есть явное противоречие. Либо речь идёт не о функциональных языках, либо последовательность действий всё таки предписана.
Вот пример на лиспе (функциональный язык):
(setvar "OSMODE" 0)
(command "_.COPY" en "" insp p1)
(setq en (entlast))
(setq ed (entget en))
Как операторы записаны, так они и будут выполнены.
Себеста не в теме :) Пусть он ознакомится с ленивым функциональным языком Haskell и скажет, в какой последовательности выполняются там функции, это раз. Во-вторых, в чистых функциональных языках компилятор при синтезе объектного кода (раз уж программа выполняется на императивном процессоре) сам планирует, в какой последовательности всё выполнять. Что-то может выкинуть, если обнаружит, что результат не используется. Представьте себе компилятор C, который выкинет вызов printf, возвращаемое значение которого не используется :D

В-третьих, Лисп — не строго функциональный язык, а мультипарадигмный, как Python и JavaScript. И те строки, которые вы привели, как раз используют императивные фичи Лиспа.

А теорема Чёрча-Россера гласит о том, что если мы вычисляем лямбда-выражение в двух разных порядках оба вычисления выдают результат (а не зацикливаются), то результат будет одинаковым.
Это все хорошо, конечно. Но ваш пример с printf не особо нагляден. Ввод-вывод вообще является side effect’ом в чистом виде, и от этого никуда не деться и функциональным языкам тоже.
Ну теперь представьте себе, что printf вызывается где-то опосредованно. Всё, вилы, лишний код не выкинешь.

Функциональные языки с этим справляются. Например, в том же Haskell функции, которые имеют побочные эффекты, имеют особый тип. Эти функции объединяют операции в цепочку, которую потом выполняет окружение. Чистая функция не может обратиться к "нечистой", потому что у неё нет доступа к началу этой цепочки — ведь данные передаются через аргументы, а тип разный...
1. Ну, раз Вы в теме, приводите подтверждения своих слов. Хотя бы в виде книжки, в которой это всё написано. Заодно можете рассказать, насколько чисто-функциональным является Хаскель, а то я как бы не в теме.
2. Я лох! Вы абсолютно правы! Функциональные языки должны выполняться на функциональном процессоре. А раз его нет (точнее, я его живьем не видел), то из этого следует, что это гениальный ход от некрософта. Вслед за выходом C# некрософт сделает собственный функциональный процессор, а интел и амд обанкротятся!!! УЖАС!
3. Вы опять таки правы, порядок операций может не соблюдаться. Даже в императивных языках. Современные компиляторы могут переставлять пары ассемблерных инструкций, если результаты их выполнения не влияют друг на друга, с целью низкоуровневой оптимизации. Думаю, о том как работает процессор, и что с чем можно переставить с целью оптимизации вы и сами в курсе ;) И что теперь, будем считать, что императивные языки не указывают порядок выполнения? Отлично! Тогда С++ поддерживает четвертую парадигму - логического программирования. Люблю я его!
4. Про принтф - это сильно! Однако язык Си - как бы не совсем функциональный. А местами даже и процедурный. И вообще предполагает, что функция может ничего не возвращать. Тип void Вы наверное знаете. И что ж теперь, все функции, которые ничего не возвращают выкидывать? :) А про передачу по ссылке Вы в курсе? Функциональные языки, как я понимаю, именно так значения и передают между функциями. Потому что по другому не могут. Потому что переменных там НЕТ!

Да-да, я понимаю, что Вы стебаетесь. Однако, хотелось бы заметить, что ни один из компиляторов ничего никогда не выкидывает из программы. Это делает оптимизатор. Подозреваю, что "парадигменность" конкретного языка может при этом нарушаться.
Да, кстати, о порядке выполнения...
В логических языках порядок выполнения определяется не компилятором в момент компиляции. А средой исполнения в процессе работы программы. Причем в зависимости от исходных условий при разных прогонах порядок может быть разный (ничего не путаю?).
1. Ну почитайте, например, Why Functional Programming Matters. Не книга, а статья, но должно хватить. Есть перевод на русский, но я его не читал и о качестве не могу судить.

А разве вам самим не очевидно, что при вычислении (2+3)*(4+5) всё равно, что вычислять вначале — 2+3 или 4+5?

2. То, что функциональные языки исполняются на императивных процессорах — это просто констатация факта. Компиляция функциональных программ для эффективного выполнения на императивных архитектурах — это очень интересная и важная задача. Что вас так возбудило, я не понимаю.

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

4. printf — это пример функции, возвращаемое значение которой в 99% вызовов игнорируется (а возвращает она вовсе не void, JFY). Конечно, в C ничего выкидывать нельзя. Я лишь проиллюстрировал оптимизацию, которая в невозможна в функциональных языках. Насчёт передачи по ссылке — я вас не понимаю. В функциональном языке значения могут передаваться как по ссылке, так и по значению, как решит компилятор. Изнутри программы вы разницу не обнаружите. Причём тут отсутствие переменных, я не понимаю.

5. Оптимизатор — это одна из самых существенных и самых сложных компонент современных компиляторов. Отделить "оптимизатор" от компилятора невозможно.

6. Последовательность выполнения операций зависит от исходных данных в любом невырожденном языке программирования (подумайте об if, switch/case и т.п.). И кстати о логических языках: при выполнении программы правила программы рассматриваются средой выполнения в строго заданном порядке. Потому что если поменять два правила местами, программа зацикливается... Никогда не наблюдали такого при программировании на Прологе? А я наблюдал.

Определяется это средой выполнения только потому, что язык Пролог не компилируется в машинный код, а так или иначе интерпретируется. Есть и интерпретаторы функциональных языков, но с практической и теоретической точки зрения лично меня интересует компиляция.
Фсё. Сдаюсь! Пусть функциональные языки выполняются как хотят!
По моему вы правы.
Ну а если так?
Язык F# основан на принципах функционального программирования, то есть в нём процесс вычисления трактуется как вычисление значений функций в математическом понимании. Это отличается от парадигмы императивного программирования, в которой процесс вычисления описывается в виде последовательности инструкций, похожих на приказы, изменяющих состояние программы.
"похожих на приказы, изменяющих состояние программы" - красивый эвфемизм для традиционного "присваивание переменной" :)
(Типа шутю.)
Нормально всё... Меня только одна фраза в статье смутила.
Sign up to leave a comment.

Articles

Change theme settings