Re: The philosophy of ruby

[Max B. <be...@ma...>]

Peter B. Shalimoff wrote:
>>>>статическая типизация нее позволяет использовать a+b для любых
>>>>объектов, на множестве которых определен +
> 
> 
> Надеялся, что при ответе Вы перечитаете эту фразу и исправите ее на то,
> что _действительно_ хотели сказать. Потому что в таком виде - это,
> извините, бред.
> 

Нельзя написать функцию которая работает с любым объектом, у которого 
есть метод add

> 
>>>При чем здесь статичность типизации?
>>
>>при том, что для получения функции, которая вызывает метод X у объекта
>>y надо в обязательносм порядке декларировать интерфейс объекта y.
> 
> 
> Интерфейс декларируется у типа, а не у объекта. Если у меня есть n
> объектов одного типа, то и вести себя они должны одинаково - как
> предписано интерфейсом. А не так, что n-1 одинаковые, а у какого-то
> одного объекта есть левый метод X, неописанный в интерфейсе. И "в
> обязательном порядке" - это даже хорошо, т.к., забыв определить нужный
> метод, в Java я получу ошибку на этапе компиляции, а в Питоне - на этапе
> выполнения. 
> 

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

> 
>>>>напиши на Java аналог функции map - у тебя не получится именно из за
>>>>того, что Java - язык статически типизированный.
> 
> 
> Вот зачем надо было это говорить, зная про Jython?
> 
> 
>>>=== Function.java ===
>>>public interface Function
>>>{
>>>  public Object call(FunctionArguments args);
>>>}
>>
>>Все - здесь статическая типизация накрылась.  
> 
> 
> Во-первых, никто и не обещал, что она останется. Во-вторых, не вижу в
> этом проблемы. Реализация функции - моя. Списки, переданные в map - тоже
> мои. Наверное, я знаю, что мне ожидать на выходе?
> 

О... если так рассуждать, статическая типизация вообще не нужна. См. 
предыдущее предложение.

> 
>>Кстати, тебе придтся для каждого случая вызова функции создавать
>>wrapper, который читебальности не прибавит. Ты сам бы стал
>>пользоваться такой map?
> 
> 
> Стал бы. Для меня BuiltIn.map(null, new List[]{l1, l2,l3}); выглядит
> читабельно. Для абстрактных "остальных", думаю, десяти перегруженных
> map'ов, принимающих разное количество List'ов, должно хватить.

я говорил про фрапперы функций. Как напримар воспользовавшись твоим map 
зключить все строки списка в кавычки.

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

то есть ты не хочешь обощать части своих скриптов и т.д.

> 
> 
>>>>- все литералы, про которые я думаю как о коллекции является
>>>>коллекцией (в том числе строка)
>>>
>>>А что мешает на Java написать класс наподобие такого:
>>
>>Ничего - городить на каждый чих врапперы конечно можно, но читаемости
>>не прибавит.
> 
> 
> Это субъективно. Два-три враппера _я_ выдерживаю.

То есть, по твоему, врапперы прибавляют читаемость?

> 
> 
>>>>- все эти коллекции доступны единообразно и существует множество
>>>>"синтаксического сахара" для работы с коллекциями
>>>
>>>В Java они доступны не менее единообразно - java.util.*
>>
>>String - не коллекция. Массив - не коллекция.
> 
> 
> Вы же только что согласились, что врапперы можно написать.

а так же писать врапперы на каждый новый тип массива.

напишите Wrapper для String [] теперь для Applet []

> 
>>>>- функции - это объекты
>>
>>врапперов не надо писать, с ними можно делать все, что с объектами.
> 
> 
> А что еще делают с функцией, кроме как вызывают?

сравнивают, передают в качестве параметра, хранят в переменных и списках.

>>как мне написать класс, кторый за меня будет писать _и читать_
>>class Program{
>>     public static void main(String args){
>>     }
>>}
> 
> 
> Не понял. Писать за Вас это будет любая IDE. А зачем это читать?

как любая IDE будет за меня _читать_ этот не относящийся к делу код.

>>Тогда я не совсем понимаю что ты вкладываешь в понятие скриптинг.
>>Для меня - автоматизация повседневных задач.
> Для меня - тоже. Вывод на печать списка строковых литералов - это не
> повседневная задача, а детский сад. Вывод на печать списка строк,
> полученных откуда-то извне (БД, парсинг файла, сеть и т.п.) - это еще
> смахивает на задачу.

эти примеры были только иллюстрацией. перед печатью можно со строками 
что-то сделать...

> 
> 
>>>>хочется ли тебе ради одноразового скрипта писать все эти Buffered
>>>>readerы и т.д.?
>>>
>>>Мне вообще никогда ничего не хочется писать. Хочу щелкнуть пальцами
>>>и получить готовую программу. Хотя, иногда даже пальцами щелкать
>>>лень. Buffered reader'ы буду использовать из-за оправданности этого
>>>использования, а не из-за n-разовости использования скрипта.
>>
>>А зачем щелкать пальцами 20 раз, если вместо этого можно щелкнуть 2?
> Кто-то же должен 20 раз щелкнуть, чтобы все остальные, включая этого
> "кого-то" могли щелкнуть только 2. Спросите у автора Питона, зачем он
> 20 раз щелкал.

Потому что питона у него не было.

Еще, питон обладает большей способностью консервировать щелчки с тем 
чтобы  дальнейшем щелкать меньше.

> 
> 
>>Чем Java для скриптинга лучше?
> 
> 
> Не знаю. Я не собирался доказывать, что Java лучше, это Вы без меня
> решили. Я просто хотел узнать, чем Питон лучше Java в плане
> кроссплатформенности. 

http://python.org/download/download_other.html

> А также все вкусности, потому что в официальной
> документации я их задолбался вычислять.

а это надо не доки, а введение на досуге прочитать.

>>>>для скриптинга лаконичность важна.
>>>
>>>Лаконичность можно и в Java сделать, написав пакет
>>>scripting.your_favourite_scripting_language.
>>
>>то есть Jython переписать - а зачем?
> 
> 
> Макс, ну что Вы как этот. Если есть готовое, то берем и юзаем. Если нету
> - пишем, а потом юзаем.

;))) вот в конце вы мне предложили писать на питоне, толькопод JVM