Команданте ибн Кандела ([info]dervish_candela) wrote,
@ 2009-10-28 02:38:00
Previous Entry  Add to memories!  Tell a Friend  Next Entry
Entry tags:haskell, питонство, программирование, трёп, философия

Why learning Haskell/Python makes you a worse programmer
http://lukeplant.me.uk/blog.php?id=1107301645

Позабавило :) Примерно подводит черту под моими отношениями с С++ после знакомства с Питоном. Может бросить хаскель пока не поздно? :)

P.S. Ощущаю всё больший этический и эстетический протест против лживых и подлых нападок на stateful-системы. Что такое алгебраические типы данных? Исходя из того, что я понял, с практической точки зрения это и есть механизм автоматического обеспечения внутренней целостности и непротиворечивости системы с состоянием. Могу предположить, что теория может быть развита далее, до автоматического обеспечения непротиворечивости и целости сложных изменяемых объектно-оринетированных систем, а собственно высокоуровневые «методы» будут прикручиваться уже сверху на полученный костяк. Технологически, часть этого уже реализована в Хаскеле. Причем, подозреваю, большая часть. Идеология объединения данных и мехнизмов их обработки, суть ООП - великое достижение, и принципиальная подверженность получающихся сложных систем ошибкам, как мне кажется, вовсе не вина подхода и уж точно не аргумент в пользу функционального стиля («битый небитого везёт», выезжать на спине других - нехорошо), а всего лишь индикатор несовершенства теоретический и технологической базы.

Всё-таки многие системы для человеческой мысли гораздо удобнее представлять в виде асинхронных сущностей с состоянием и методами, чем в виде деревьев вызова чистых функций. Именно это и стало причиной появления и формулировки данной проблемы. Будь нам функциональная парадигма ближе, этой проблемы бы даже не появилось.


(30 comments) - (Post a new comment)

Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-28 02:03 pm UTC (link)
1. В заголовке чувак шутит.
2. На C# 3.0 код из примера выглядит куда приличнее.
3. ООП и ФП отлично сочетаются, если не требовать повальной чистоты.
4. Про понятность и удобность императивного кода молчу. :)

(Reply to this) (Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-28 05:28 pm UTC (link)
1. А мне нельзя? Но вообще я по сути: после питона программирование на С++ превращается в вечное уныние в стиле "а вот я бы сделал вот так...". Именно об этом и речь, а вовсе не о том, что нельзя учить языков лучше Блаба.
2. см. 1
3. ну так а я о чем? =)
4. вы говорите "императивный" так, как будто это что-то плохое =) а если серьезно, то плохой код можно писать в любой синтаксической парадигме. И функциональный код может как выполнять свою роль (реализовывать декларативную методологию) в умелых руках, так и нет (быть ухудшенной версией процедур).

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-28 09:43 pm UTC (link)
3. ООП не означает автоматически "систему с состоянием", т.е. хранение состояния в "потоке выполнения" (что и является основной характеристикой императивного кода). Функциональность и объектная ориентированность практически ортогональны. Простым примером такого утверждения являются иммутабельные структуры данных: от привычного класса-коллекции такой класс отличается тем, что методы, манипулирующие содержимым, вместо изменения исходного объекта возвращают другой, который содержит ссылки на изменённый набор данных.
4. Функциональный код не может не быть декларативным. :) Но форма декларации может быть, очевидно, насколько угодно неудачной.
1. Я так подозреваю, в уныние тебя превращает скорее общий синтаксис C++ или его статичность. На нём тоже можно писать функционально, хоть это и может казаться не очень естественным.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 10:05 am UTC (link)
3. Простестую. Смысл сегодняшнего ООП сводится к синтаксическому сахару, если выкинуть из определения состояние. Хотя я не против, чтобы это сделали. Но традиционное ООП - это именно состояние + методы его изменения.

Также протестую против размахивания словом «императивный». Императивный, насколько я понимаю, озанчает «командный», речь идет о задании последовательности действий. Декларативный означает описание требуемой системы вместо задания последовательности действий. Часто оба подхода могут быть использованы с успехом (в инженерии, или электронике например) для описания одной и той же системы вполне успешно, и дополняя друг друга (т.е. не только стили "функциональный" и "структурный/ооп" ортогональны, но и подходы "декларативный" и "императивный" точно так же могут дополнять друг друга).

При этом функциональный стиль, как мне кажется, вовсе не является единственно возможным для реализации декларативности.

4. может. но это уже вопрос терминологии. является ли декларативным эмулятор императивного кода на хаскеле? :) во-во. Как по мне, вопрос не стоит выеденного яйца.

1. Да-да =) Ты верно понял. Только не "фнукционально" (всё-таки функции там - граждане второклассные и очень бедные), а "декларативно" - пользуясь идиомами из STL, например, и программируя сверху вниз. Но С++ очень затрудняет эту работу тем, что его мясо - это императивка низкого уровня, это структурный, процедурный код на С. (т.е. чтобы написать идиому foreach, я должен фактически вбить в код последовательность вызова и использования итераторного протокола =)

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 12:01 pm UTC (link)
1. Функции без побочных эффектов запросто пишутся на любом языке. Алсо, http://en.wikipedia.org/wiki/Functional_programming#Functional_programming_in_non-functional_languages и http://www.boost.org/doc/libs/1_40_0/doc/html/lambda.html
С синтаксисом, конечно, ничего не поделаешь.

4. Где-то там наверняка будет использоваться монада IO, контейнер для императивного программирования на Хаскелле. :)

3. Создание и возвращение нового состояния вместо изменения старого ничему в принципах ООП не противоречит. Они больше определяют принцип декомпозиции задач, чем их решения.
Из примеров, есть scala.collection.immutable, Clojure с его полностью иммутабельными коллекциями и, разумеется, структуры данных в более старых гибридных языках типа OCaml'а.

Декларативный и императивный могут друг друга дополнять в смысле чередования. Сами подходы в рамках программирования считаются противоположными. Как пишет вики, кроме функционального, декларативным считается также "логическое" программирование, о котором я лично знаю только слово Prolog.
Разные задачи может быть удобно решать по-разному, но, чаще всего, если решение поддаётся функциональному стилю, оно в нём выглядит проще и элегантнее (заранее, контрпример -_-).

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 12:27 pm UTC (link)
1. Не совсем. Помнишь тот блог, с "Краткой и неверной историей..." ? Там помню атвор долго растекался по теме () (unit/bottom). Финальная мысль в том, как я понял, что исключение или невозвращение значения тоже является побочным эффектом, а системы типов в старых языках никоим образом это не учитывают. А в том же хаскелt невозвращение значения - это отдельный тип (во тличие от С, где void - это просто карт-бланш на тайпкасты, т.е. любой тип)
.. о чем это я ... а, ну да. можно имитировать ФП на С++, но это не слишком благодарная задача. А просто разбиение на фукнции и построение программы соединением их руг с другом - это, извините, ещё не ФП, это старое доброе процедурное программирование. Ну и про синтаксис ты очень верно заметил =)

4. Конечно. Почему я и хочу сказать - если один и тот же код может быть легко назван как декларативным, так и императивным, то это не определения каких-то технологий, а описания того, как мы о технологиях думаем. Это методология.

3. А кто говорит против? Я говорю о том, чем ООП является. Сегодня, на практике. Я совершенно не против, чтобы оно технологически и идейно развивалось =) В чатсности, я считаю иммутабельные данные как метод программирования ересью - это должно быть частью технологии, а не частью моих мыслей. Иммутабельные данные ведь решают вполне конкретную технологическую задачу - избавиться не от собственно изменяемого состояния, а от его недостатков (мучительная смерть всего и вся при конфликте доступа или нарушении целостности, например). а) Если у меня алгоритм по преобразованию данных, то мне всё равно (пусть под крышкой все данные будут иммутабельны, и каждая копия иммутабельных данных будет дешевой - это чисто технологический вопрос, не дизайнерский). Я с радостью напишу цепочку функций и даже ни разу не задумаюсь о том ,что воспользовался Функциональным Подходом™
б) Если у меня состояние, то мне оно в любом случае нужно, сколько про иммутабельность ни жужжи (пусть опять же под крышкой научатся делать его правильно - например, задйствовать всё то, что уже давно работает в RDB - умеют же там работать с изменяемым состоянием, решать конфликты, проводить транзакции, сохранять целостность итп).

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

Если же говорить о методологоии... Скажем, структурная схема системы стабилизации - декларативна на 100%. А её описание в словах, в последовательных терминах - императивно. С одной стороны, по проводам бежит ток с конечной скоростью, поэтому всё рпоисходящее представляет из себя последовательность во времени. Да и понять мозгами принцип работы можно только разобрав именно так. А с другой стороны, изучить её поведение и характеристики можно уже математически, в целом виде (и понять и узнать то, чего не дает последовательный разбор). И то и другое на 100% корректно, и они дополняют друг друга.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 01:36 pm UTC (link)
1. Там было не про побочные эффекты, а просто про то, что пустой тип - это дырка в системе типов. Как и исключения, потребность в которых стандартно обходится с помощью монады Maybe.
Но это совершенно не важно, чистая функция не может иметь пустой возвращаемый тип, т.к. это автоматически означает, что она ничего не делает. Писать их можно на любом языке, вопрос только в том, как на них разложить решаемую задачу.
>> С, где void* - это просто карт-бланш на тайпкасты, т.е. указатель на любой тип
FTFY

4. Наверное, ты задал неправильно поставленный вопрос. Декларативным может быть не эмулятор (что бы это ни было), а способ его написания в коде.

3. Даже сегодня приведённые примеры используются на практике. Но, конечно, не в C++.
Иммутабельные данные не могут не быть частью ментальной модели, т.к. надо хотя бы помнить, что каждый раз при манипуляции нужно сохранять и использовать ссылки на новые объекты.
Решение проблемы конфликтов для мутабельных структур данных - это задача STM, и у этого подхода есть свои плюсы и минусы.

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 01:58 pm UTC (link)
1.
Как это не может? Мы же можем возвращать Nothing?

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


4. Вопрос был риторический =) Эмулятором является do-инструкция хаскеля, прячущая от нас весь монадный механизм. С точки зрения человека, do-последовательность действий в IO-монаде является 100% императивным, процедурным кодом с немного необычной формой записи.
В отличие от неё, какая-нибудь foldr (>>) somelist (или как там) - уже очевидно декларативно.

3. Кто ж против? :) Только - зачем. Если компания пишет код на яве там, где нужен эрланг - бежать с такой компании надо.

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 02:13 pm UTC (link)
1. Если Nothing валидное значение из пространства значений функции и оно несёт в себе полезную нагрузку (в массиве искомого значения нет), то к () или void оно не имеет никакого отношения. Только в системе со статичной типизацией его надо как-то интегрировать, для этого и сделана монада Maybe.
Если метод возвращает void, то никаких других значений он не возвращает никогда.

4. Это кажимость. :)
При использовании монады IO имеет значение порядок операций, посему код нечистый.

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 02:27 pm UTC (link)
1. Надо учить =) Покая слабо в этом ориентируюсь.
А вот фигушки. Он может НЕ вернуть void, — например, при исключении или в случае exit(), как тот чувак писал (не знаю как там у вас в яве). Сосбтвенно, дырка она и есть дырка.

4. Кажимость чего именно? Какое отношение имеет декларативность к чистоте? Что-то я не воткну.
Он не "имеет значение", а "обеспечивается". "Значение" - это семантическая категория, её дает человек =) Программе-то всё равно. Почему я и говорю, что я бы однозначно определил do-инструкцию как императивку (т.к. МЫ, человек, указываем что делать и в каком порядке), а второй вариант - как декларативный (мы просим "сделать всё"). И в том и в другом случае порядок обеспечивается.

3. Я просто не совсем уверен, не смешиваем ли мы уровни абстракции. То, что мы видим поведение прежде абстракций, это-то понятно. не совсем понятно ,по каким критериям поведенческий уровень - "более низкий".

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 02:49 pm UTC (link)
4. Про "кажимость" - это я на какой-то свой вопрос отвечал. -_-
Порядок операций обеспечивается монадой, потому что он задаётся в коде, использующем монаду. И то, что он важен, означает императивность как кода, так и получившейся конструкции. Хаскелл по-простому писать императивный код не позволяет, поэтому когда есть необходимость, приходится прибегать к таким решениям.
Насчёт "второго варианта" не понял. "Чистой" альтернативы такому коду нет.

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-30 09:07 am UTC (link)
Хм, там оказалось всё немного сложнее. Но речь шла в любом случае не о чистоте ,а о форме представления. Если я ничего не путаю, то примерно так: можно писать всё в виде do-нотации, это императивка. а можно занести все действия в список xs и использовать «foldr (>>) (return ()) xs» - это будет уже декларативный подход - у нас есть данные (список) и описание того, что с ним нужно сделать (выполнить все действия из списка). Хотя механизм абсолютно идентичен, и за do-нотацией стоит тот же самый >>= (и return), что стоит за >> .

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-30 03:25 pm UTC (link)
Уу, какие суровые символы. Тут не помешали бы работающие примеры.
Если xs содержит "действия", а не выражения, то процесс уже построен на непрозрачных основаниях, и чтобы в нём был какой-то смысл, потребуются переменные, принадлежащие пересечению области видимости методов, которые в процессе выполнения меняли бы значения.
А если бы там были функции типа a -> a, то получился бы обычный конвеер, который без списка можно записать в виде f(g(h(x))).

Что такое "технология"?
Слово "процедурный" использовать не стоит, т.к. им называют стадию развития организации программного кода до популярности ООП.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-11-02 07:13 am UTC (link)
аа, я так и не ответил же.
сорри.

это практически буквально взято из http://book.realworldhaskell.org/read/io.html
я бы руками не написал (я пока не очень понимаю, как именно работает (>>) + «return ()»
т.е. идея мне понятна, но вот детали - не очень.

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

Касательно типа, монадные sequence и sequence_ выполняют как я понял любые a -> IO a (а то и a -> IO b). Первая - это без отбрасывания, используя (>>==).

«технология» - это субстанция, заполняющая пропасть между мечтой и реальностью :) (более формальных определений я не знаю).

Я именно "процедурный" и имел ввиду. Что такое объект в С++ ? признак класса (т.е. таблица адресов методов) и данные. Весь код, делающий работу - процедурный. Перебор коллекции с помощью for(SequenceT::iterator i = sequence.begin(); i!=seqence.end(); i++) - это чистой воды процедурный код (и stl::for_each под крышкой, я уверен, выполняет то же самое). А что такое декларативность в С++ ? Это и есть широкое использование шаблонов. Всё остальное - это процедурка.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-11-02 09:25 am UTC (link)
>> не уверен, что значит "непрозрачные основания"
В примерах единственное, для чего используется монада, это чтение ввода и вывод (и т.о. результат выполнения метода зависит не от входных параметров, которых нет, а от подсистемы ввода-вывода). Если пытаться с такой моделью делать что-нибудь более полезное, то потребуется использование переменных в общей области видимости и т.п. Каждое из этих действий - не чистая функция. В силу возможности написания такого кода, некоторые считают Хаскелл не чистым языком.

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

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-11-03 09:53 am UTC (link)
> В примерах единственное, для чего используется монада, это чтение ввода и вывод
эти IO в списке могут вообще ничего не писать и не читать, как я понимаю.

> Каждое из этих действий - не чистая функция.
Да, но они могут вызывать сколько угодно чистых функций

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

Это не логика. Это практика. А практика заключается в умении установить практически релевантные границы и критерии (рекурсивное определение, лол. welcome to Kant). Мы же не вспоминаем каждый раз, что механизмы состоят из атомов. Мы рассматриваем сразу шестеренки. Хаскель воплощает абстракции из области лямбда-исчисления, теории типов и категориальной логики, а С++ ничего из этого не делает, вот и всё :)

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-11-02 08:06 am UTC (link)
в узком смысле, «технология» - это реализация, воплощение решения задачи. у нас это технологические карты, оборудование, станки, приспособления - техпроцесс. В прграммировании это совокупность конкретных инструментальных и методических средств обеспечния - от граматик и компиляторов до интерфейсов и библиотек (аналог наших деталей, комплексов, гостов).

Кстати, с днем рождения (мне жижа напомнила. не могу поверить, что люди забивают в интернеты свои реальные данные ;)

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-11-02 08:50 am UTC (link)
Спасибо. Надо не забыть стереть. :)

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

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-11-02 08:10 am UTC (link)
а ещё есть стрелки, которые более общий вариант монад :)
меня порадовало, что в ФП чем сложнее концепции, тем более простые идеи стоят за ними с высоты птичьего полёта :) (по-крайней мере объяснение стрелок с помощью конвейерной метафоры было вполне понятным, зато разобраться в деталях их работы, вотличие от монад, я даже не надеюсь ^^;;;)

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 02:05 pm UTC (link)
>> Иммутабельные данные не могут не быть частью ментальной модели, т.к. надо хотя бы помнить, что каждый раз при манипуляции нужно сохранять и использовать ссылки на новые объекты.

в случае со строчками мы уже успели убедиться, что всё отлично работает? Частью ментальной модели в обязательном порядке будут не сами иммутабельные данные (что всегда звучит противоестественно), а подобие «pointfree»-стиля — акцент на конвейерах обработки вместо (привычного нам процедеурного) акцента на переменных и их изменении.

>> Решение проблемы конфликтов для мутабельных структур данных - это задача STM, и у этого подхода есть свои плюсы и минусы.
Ух ты :) Всё за нас придумали. Очень интересно.
Я со своей ламерской колокольни думаю, можно было бы в итоге сделать что-то типа сплава ООП, АлгТД и software-only STM как возрождение ООП - сохранить красивенькие плюшки ООП без бороды его минусов.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 02:20 pm UTC (link)
В случае со строками мы успели убедиться, что вы с товарищем ожидали, что строчка меняется при replace: потребовалось изменение ментальной модели.
Конвейерность использовать удобно, но надо и осознавать, что исходная строка не меняется. И помнить, когда меняется: в том же C++ перед заменой было бы ручное копирование строки.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 02:32 pm UTC (link)
говорю же, вопрос акцентов =) куда проще принять иммутабельность, когда она вытекает rfr необходимое и логичное следствие из новой модели, чем когда она кормится тебе как аксиома и идол, на который надо молиться и мазать ему губы медом, а спину - вареньем :)

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 02:18 pm UTC (link)
дырка в системе типов - это разве не есть побочные эффекты?
елси функция делает что-то, что её тип не предусматривает, это, как я понимаю, и будет побочный эффект.

Впрочем, тут мне ещё учить и учить. Система типов в Хаскеле велика и могуча, заставляет ощутить собственную ничтожность в полной мере ;)

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 02:31 pm UTC (link)
Не совсем. Если функция парсит число из строки и бросает исключение, если строка не парсится, и больше ничего нелегального не делает, но она будет фактически чистой, т.к. она ведёт себя одинаково, когда бы и сколько бы раз её ни запускали.
Только формальное определение "прозрачности" не применить, т.к. понятие "возвращаемое значение" для неправильных параметров не определено. Если систему типов доопределить для такого поведения, функция станет и формально чистой.

Я Хаскелл практически не знаю, btw. :)

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 02:34 pm UTC (link)
ага! тогда... что?
я забыл, что мы обсуждали ^^;;

ладно, вечером перечитаю всю дискуссию заново и подумаю.

ничего, я тоже Хаскель практически не знаю =)

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-11-02 07:22 am UTC (link)
тогда можно ли сказать, что чистота - примерно то же самое, что детерминированность?

(Reply to this) (Parent)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 01:33 pm UTC (link)
отличный пример того, как иммутабельность не обязана мозолить глаза - те же строчки в питоне. Все становятся на уши, впервые прочитав в учебнике строчку "строки неизменяемы", но никто не даже не задумывается об этом на практике :)

>> s = "lol"
>> s = "fine, but where's the 'immutable' part?"
>> s
"fine, but where's the 'immutable' part?"

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 01:41 pm UTC (link)
Строчки много где иммутабельны. :)
В этом примере нет ничего особенного, никто не говорит, что переменной нельзя присвоить другое значение.

>>> a = "fine, but where's the 'immutable' part?"
>>> b = a.replace("fine, but where", "here").replace("?", "!")
>>> a
"fine, but where's the 'immutable' part?"
>>> b
"here's the 'immutable' part!"

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]dervish_candela
2009-10-29 01:50 pm UTC (link)
ну, я впервые стокнулся с этим в питоне. мой коллега и я оба высели на измену ,а на практике оказалось, что об этом вообще можно не думать (как и о том, что имена являются ссылками). Человек просто привыкает, что a.replace() не изменяет a, вот и всё. (хотя я однажды сел впросак, да...)

именно. туда иммутабельности и дорога.

(Reply to this) (Parent)(Thread)
Re: Why learning better languages makes you a worse programmer
[info]hakubo
2009-10-29 02:01 pm UTC (link)
Она давно уже там. :)

(Reply to this) (Parent)

(30 comments) - (Post a new comment)

Create an Account
Forgot your login or password?
Login w/ OpenID
English • Español • Deutsch • Русский…