?

Log in

No account? Create an account
о программировании - Сделать невозможное (камень -> пар) [entries|archive|friends|userinfo]
Сделать невозможное (камень -> пар)

[ website | Мой основной блог ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| Мой блог о личностном росте Vim-Erlang package Translation tool Пошли свои страхи на ... Задолбали длинные линки? ]

о программировании [Feb. 11th, 2011|03:30 pm]
Сделать невозможное (камень -> пар)
[Tags|]

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

Иначе они даже в OO модели пишут классический спагетти код - с сайд эффектами, с использованием переменных класса в качестве глобальных переменных и т.д.

классический пример (на php)

$data = $this->validate($data);
if (isset($this->validation_results)) { ... }

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

list($data, $validation_results) = $this->validate($data);
if ($validation_results) { ... }

Я лично считаю, что это идет
  • во-первых от того, что пишущий никогда не задается вопросом - а как я могу красиво вернуть сразу _несколько_ результатов из функции - это тяжелое наследие языка типа Pascal/C, где для этого пришлось бы создавать отдельную структуру
  •  

  • во-вторых, из-за недостатка кругозора в других языках программирования. Даже в том-же самом Python (который уже стал мейнстримом) упаковка/распаковка данных из tuple является очень синтаксически естественной операцией и читая чужой код, учащийся языку воспринял бы эту конструкцию и начал ее использовать. В php это не так принято - и поэтому на нее и не обращают внимание. Написание двух лишних слов array/list в php я не считаю препятствием - просто небольшое неудобство.

В этом плане мне очень нравится подход perl, который даже ссылку на экземпляр объекта передает в качестве аргументов функции - поэтому, когда начинаешь менять что-то в экземпляре объекта - сразу видишь, что в этот момент создаешь side effect :)

Резюме: учите другие языки программирования, хотя бы для расширения кругозора ;)
LinkReply

Comments:
[User Picture]From: smbatgogyan
2011-02-11 11:47 am (UTC)
Urish lezu petq chi, menak C++ heriq e
(Reply) (Thread)
[User Picture]From: nm_work
2011-02-11 05:07 pm (UTC)
C++ редчайшее уродство :))))

городить огромный и сложный огород, только из-за того, что язык не поддерживает динамическую типизацию и еще много вкусностей языков более высокого уровня? неее. нафиг-нафиг такие оладушки :)
(Reply) (Parent) (Thread)
[User Picture]From: smbatgogyan
2011-02-11 09:20 pm (UTC)
esim, achqis sirum es fast food :-D
(Reply) (Parent) (Thread)
From: ex_norayr
2011-02-14 09:47 am (UTC)
ապ, եթե դու չես սիրում, ապա ինչու C++ օրինակ բերեցիր, ու ոչ C-ն։ կամ ոչ ասմը։
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-15 02:37 pm (UTC)
все существенно проще, я люблю языки, которые экономят _мое_ время при написании программ.

даже интерпретируемые языки полностью подходят для большинства задач, так как реально оптимизировать по скорости нужно где-то 10% кода, не больше. а все оставшееся вообще тупо ждет и простаивает, пока пользователь среагирует :))))
(Reply) (Parent) (Thread)
From: ex_norayr
2011-02-14 10:06 am (UTC)
дело не только в высоком уровне.
вот хорошая ссылка http://yosefk.com/c++fqa/defective.html
(Reply) (Parent) (Thread)
From: ex_norayr
2011-02-14 10:09 am (UTC)
для меня важной концепцией является encapsulation с которым в C все плохо.
(Reply) (Parent) (Thread)
[User Picture]From: Grigory Javadyan
2011-02-14 10:17 am (UTC)
у меня в старом журнале был пост про инкапсуляцию в Си :)
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-15 02:38 pm (UTC)
ну :) для меня нет - так как C надо использовать именно для того, для чего он хорош - для написания небольших и очень быстро работающих вставок кода.

а там обыкновенно можно обойтись спокойно и без инкапсуляций и прочего :)
(Reply) (Parent) (Thread)
[User Picture]From: Grigory Javadyan
2011-02-14 10:17 am (UTC)
Динамическая типизация - страшная штука.
Покрывать свой код кучей юнит тестов чтоб исключить ошибки типов - мазохизм. Поэтому динамическим языки применимы для скриптования и быстрого прототипирования. Потому что быстро и думать не нада (к тому же когда добавляешь методы к объектам "на лету" в первый раз появляется ощущение, похожее на оргазм, но потом понимаешь, что это не нужно, опасно и уничтожает саму концепцию типа).

Цпп хорош именно потому, что он позволяет красиво реализовывать высокоуровневые абстракции, оставаясь при этом system-level языком со статической типизацией и прочими прелестями.
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-15 02:31 pm (UTC)
ты не поверишь - в C++ катастрофически кривая и усложненная концепция типов :)

если хочешь посмотреть очень красивую реализацию, при этом в динамическом языке - Haskell тебе в руки ;) и наследование и полиморфизм -- просто заглядение.

факт номер 2 - erlang вообще обходится без жесткой типизации (atom/number/tuple/list/binary) и отлично живет :)
(Reply) (Parent) (Thread)
[User Picture]From: Grigory Javadyan
2011-02-16 02:31 pm (UTC)
> динамическом
> Haskell

лолшто
http://en.wikipedia.org/wiki/Haskell_%28programming_language%29
> Typing discipline *static*, strong, inferred

про то, что в плюсах есть проблемы с системой типов я не спорю. Но он все равно лучше любого динамического языка для меня.
(Reply) (Parent) (Thread)
From: ex_norayr
2011-02-14 10:14 am (UTC)
microsoft-ը ի դեպ այլեւս չի թողնում Windows Phone-ի համար C++-ով գրել, ինչպես եւ առհասարակ նեյթիվ կոդ օգտագործել - միմիայն դոթնեթ։ չեմ ասում որ լավ քայլ ա, պարզապես fyi էլի։
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-15 02:35 pm (UTC)
ну и правильно, зачем извращаться на low-level языке :)
(Reply) (Parent) (Thread)
[User Picture]From: Grigory Javadyan
2011-02-16 02:32 pm (UTC)
performance
total control
(Reply) (Parent) (Thread)
[User Picture]From: nm_work
2011-02-16 06:27 pm (UTC)
тебе не нужен _total_ control :) реально оптимизация 10-15% кода убирает все узкие места с производительностью. оставшееся может выполняться хоть вручную ;) оно все равно не повлияет на конечный результат :)

я понимаю, хочется "чувствовать себя богом" - но на практике это нафиг не надо :)

(Reply) (Parent) (Thread)