?

Log in

No account? Create an account
   Journal    Friends    Archive    Profile    Memories
 

Питоновское - morfizm


Jun. 20th, 2012 02:29 am Питоновское33 comments - Leave a commentPrevious Entry Share Next Entry

Comments:

From:morfizm
Date:June 25th, 2012 05:22 am (UTC)
(Link)
Я твой подход полностью разделяю - для сегодняшнего дня.
Но подумай над будущим: уже сейчас есть огромное количество задач, когда дополнительная железка дешевле, чем тот *константный* прирост производительности, который ты получишь, если напишешь ручками более оптимизированный код. А что будет дальше?

У меня есть подозрение, что интимные знания о структурах данных через несколько лет будут локализованы среди разработчиков компиляторов, а также в embedded & low latency/realtime, а подавляющее большинство будет успешно обходиться с тем, что оптимизирующий компилятор сделает с твоей одной абстракцией на все случаи жизни, вроде dict.
From:sasha_gil
Date:June 26th, 2012 02:43 am (UTC)
(Link)
Мне кажется, кроме возможности оптимизации выразительность языка играет роль для улучшения читабельности и поддерживаемости кода. Возьмём для примера Perl. Я на нём не писал, но выскажусь. Там, с одной стороны, универсальный контейнер вроде dict назван не как-нибудь, а хэшем (имеется в виду hash table), т.е. то, что логически есть ассоциативный массив ну или мэп, названо по имени выбранной реализации. Во-вторых, программы на нём трудно читать. Эти два факта кореллируют: автор языка совсем не заботился о подборе "правильных абстракций", сделал язык для хакеров. Это важная ниша (ты правильно пишешь про "подавляющее большинство задач"), однако я больше интересуюсь программированием долгоживущего кода (именно на этом хочу сделать упор, не на оптимизациях вручную).
From:morfizm
Date:June 26th, 2012 06:17 am (UTC)
(Link)
Мне кажется Perl трудночитаем вовсе не из-за того, что там одна абстракция на все случаи жизни, а по ряду других причин. Но мне перл тоже не нравится, так что нам тут не удастся поспорить.

Твой поинт понятен :)
Но я попробую побороться.
Почему выбор абстракций для читаемости авторской задумки должен диктоваться фичами языка, а не библиотеками или with syntax sugar? Вот смотри: даже в том же Питоне нет такой абстракции как "очередь". Используется класс, потомок от списка, с методами append() и popleft(). Если уж идти вразнос и делать каждую структуру данных фичей языка, то почему бы не изобрести какие-нибудь там двойные квадратные скобочки для очереди, и не сделать её first-class объектом? Не делают этого, ибо нефиг. Потому что абстракций дофига, правильно? Соответственно, first-class объектов должно быть поменьше, а свободы надо закладывать в subclassing/extensions/libraries/syntax sugars/etc. А если first-class объектов должно быть поменьше, почему бы не сделать ещё поменьше? :)
From:(Anonymous)
Date:June 29th, 2012 06:44 am (UTC)
(Link)
Я согласен с моделью минимального ядра языка и контейнерами и прочими удобствами в библиотеках. Так развивается C++, например (в ядре один контейнерный тип -- массив из C, зато STL определяет контейнерные абстракции и ряд настраиваемых реализаций этих абстракций). Да, может быть, Пайтон мог выиграть от такого упрощения. Я сейчас имею дело с JavaScript, там, наверно, попроще, но несколько напутано тоже (как сейчас кажется - на пустом месте). Ты не изучал, случаем, Ruby?
From:sasha_gil
Date:June 29th, 2012 06:47 am (UTC)
(Link)
(потерял ответ, так как был не залогинен) - твои доводы убедительны, я подумаю / посмотрю ещё на досуге (например, узнаю, как с этим делом в, скажем, Ruby и Lua).