Численно оптимальность подхода выражается в человекочасах, затраченных на решение. Оно включает не только написание кода, но и архитектурное проектирование, отладку и последующее сопровождение (другими программистами). Вполне вероятно, что начиная с комплексных задач средней сложности, Ваш подход перестанет быть оптимальным. Проект погрязнет в ошибках, программисты, пришедшие в проект не будут понимать код других... можно брать лопату и хоронить.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
Ну и в чем смысл size()? Что он измеряет? Размер в байтах, в элементах или в попугаях? В java для этого служат интерфейсы. Например Comparable служит для любых сравнимых сущностей. Collection - для всего, что может содержать элементы. Так что никакой четкоопределенной универсальной абстрактной функции у size() нет.
Далее. Строгая типизация просто необходима. 30-летний опыт показывает, что она - в момент компиляции обнаруживает большинство ошибок. Не даром в java добавили generics.
Ничего принципиально нового в Closures нет. Он использовался еще в C как паттерн function callback. Но уже в C++ он стал одним из антипаттернов и заменен более адекватными шаблонами (типа Iterator).
Я согласен с Вами, что основная задача groovy - удобство и скорость программирования. Однако удобство и правильность - разные зачастую несовместимые понятия. Это как искусство и коммерция. Программирование, шаблоны, ООП и языки выросли из философских соображений, нежели из соображений удобства, и имеют определенную идею. Гослинг, разработавший Java - идейный человек, а разработчики groovy - комерсанты, завлекающие разработчиков удобством.
В моем примере контроль типов съел хабр (он подумал, что это html тэги).
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Я так понимаю, что это транслируется в код, который сначала делает LinkedHashMap, а потом из нее HashMap ;)
Умолчания - для молчунов. Вся документация по groovy - это сборник рецептов и враперов для уже существующих api. Никакой формализации, никакой структуры. Словом, помойка для удовлетворения сиюминутных потребностей. Еще раз повторяю, что closures - абсурд. Не понимаю, чем он лучше функционального подхода? В чем философия Collection.each() ? Сама коллекция не имеет свойства обходить свои элементы и делать с ними что-то, пришедшее извне. И не нужно ее учить это делать при помощи closures. Коллекция - для хранения элементов, не более.
Не понятней. Во-первых, где контроль типов в вашем мепе? Во-вторых, какой имплементирующий тип мэпа возвращает эта конструкция: HashMap, TreeMap, LinkedHashMap или VasyaPupkinInternalMap? В-третьих, как ведет себя сия коллекция в многотредовой апликации? Является ли она синхронизированной или нет?
Ответы на эти вопросы остаются за кадром и не ясны из контекста. В итоге язык усложняется и обрастает ненужными конструкциями и допущениями. А это возврат на 30 лет к PL/M (думаю, молодые программисты даже не знают что это такое). Все последущие языки эволюционировали в сторону упрощения, то есть при помощи минимальной функциональности и простоты покрыть максимальный объем задач. А вовсе не как сократить количество символов в программе. В итоге был найден определенный компромисс, который имеют все структурные языки. Функциональность расширялась за счет подключаемых библиотек или ООП.
Скриптовые языки типа groovy не являются структурными ибо служат для написания сценариев в уже существующей архитектуре и не более того. Писать что-либо серьезное на groovy будет большой ошибкой.
Вы про то, что в Java нет константной инициализации мепов? Так это любой школьник напишет. Например так:
final String[] mapConst = {"key1","value1","key2","value2" };
Map map = new HashMap();
for ( int i = 0; i < mapConst.length; i+=2 )
map.put( mapConst[i], mapConst[i+1] );
При этом не уродуется язык, а функциональность расширяется за счет собственно функций.
Ну, например, некоторые компоненты OpenOffice написаны на Java. Сообщество боялось, что с закрытием java может прийти конец лафе. Это было основным сдерживающим фактором в использовании java в GNU системах. Правда сообщество разрабатывало свою java машину (GCJ и GNU classpath). Собственно это не совсем VM, а надстройка над GNU C, с возможностью компилировать и выполнять байткод. GCJ сильно не дотягивает до полной функциональности и спецификации Java. Ради привлечения народа и денег в сферу java Sun решила ее открыть.
Лучшая каптча. Для получения привилегий на пост на форуме необходимо отправить смс. При обнаружении spam-activity (флуд, повторный пост, визуальная проверка) привилегии удаляются.
final String[] animals = {"lion", "tiger", "bear"};
for ( String a : animals )
System.out.println( a );
Тем, что проста, понятна, последовательна, легко отлаживаема и выразима на любом алгоритмическом языке? К чему извраты вроде code injection в коллекцию объектов с абстрактным итератором? Как Вы будете пошагово отлаживать свой код, если надо сделать более сложные вещи, нежели вывод объекта? Closures в Java - зло! Java не нужны новые идеи - она самодостаточна.
А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования. Декларативное программирование и скриптовые языки хороши там, где кончается архитектура и начинаются прикладные задачи, типа определения бизнес правил и написания сценариев. А весь используемый функционал имплементируется фреймворком более низкого уровня, написанном на нормальном языке типа Java или C/C++.
Mills says that this work, which he terms "Classical Quantum Mechanics", is entirely based on classical physics and special relativity, rejecting quantum theory.
Говоря о состояниях электрона в атоме водорода ниже нулевого уровня, аффтар оказывается не использует квантовую механику, а пользуется все той же классической физикой. Дальше смотреть будем?
Mills says that the electron is an extended particle which in free space is a flat disk of spinning charge.
А завтра он скажет, что Земля - тоже диск.
The Grand Unified Theory of Classical Quantum Mechanics, which he distributes electronically... Superconductivity... Dark matter... The accelerating expansion of the universe...
Обязательно любая новая теория должна объяснить сразу все.
hydrino in 1991 to explain the excess heat reported in 1989 by cold fusion experimentalists
...и присосаться в наиболее скандальных местах, чтобы быть замеченой.
В наш век, век глобальных дезинформационных технологий, без критики просто не обойтись ;)
В актуальном OpenJDK, который сейчас по дефолту поставляется с ubuntu 8.04, сильные баги с Java2D рендерингом и имидж-процессингом. В результате моднючие свинговские шкурки типа Substance не работают. Приходится ставить все тот же JRE от Sun.
Кстати, ничего особо положительного в открытости Java я не вижу. Студенты-гнушники превратят ее в большую помойку, полностью разрушая идейность и стройность языка и платформы. Ради получения выгоды от сокращения двух строчек кода в язык встраиваются жуткие рудиментарные конструкции, пришедшие из скриптовых процессоров (посмотрите полный список proposals к Java 7).
Радикальные изменения затронут также и саму VM. Java все больше будут привязывать к платформе GNU, возникнут различные форки проекта, и в результате один и то же софт больше не будет "write once, run everywhere".
Насчет развивающихся стран не согласен. Вот например Китай. Он полностью разрушил производство в Европе/Америке ввиду своих низких цен на рабочую силу. Пройдет еще лет 10 и они вырастят своих инженеров. Производство, спасибо западу, уже поднято. Китай станет самодостаточным государством. А вот возбновить за 10 лет разрушенное производство на западе - задача нереальная. Таким образом западные технологии останутся невостребованными (кому они нужны без производства?). Если конечно не возьмутся за арабов или негров...
А че у меня с этим долбаным пульсаудио не работал флешик и скайп? Все обещали типа Алса всецело и полностью эмулируется и все такое. Реально - нет ни одного достойного решения чтобы вышеперечисленные апликации заработали.
А вообще, купите звуковушку с hardware mixing типа Creative, и не парьтесь с этим PA!
Не знаю как в России, а в Европе контент сайта можно защитить авторским правом (а также программу и базу данных). Для этого есть специальный реестр. Думаю, сначала нужно выявить фирму, стоящую за сайтом. Затем нужно нанять юриста, который приготовит материалы, доказывающие копию, а также подаст заявку на защиту контента авторским правом (если это возможно). После этого необходимо написать грозное письмо с просьбой убрать копирайтные материалы с другого сайта. Если владельца выявить не удается, нужно действовать через провайдера.
Справедливое замечание. Те, кто думает, что суд мигом решит все их проблемы ошибаются. Это больше так, для запугивания. Сначала придется потратиться на юриста, потом начнется тягомотина, собирание бумажек и доказательств. Затем слушание, потом возможно еще одно. И есть определенная вероятность, что несмотря на все, решение будет не в вашу пользу. Есть более эффективный способ заработать деньги.
Более того, в информационных технологиях судья как правило ничего не понимает, а посему доказать факт выполненной работы становится невозможным. Вот если бы вы строили дом - это другое дело. С другой стороны, в информатике всегда есть возможность восстановить справедливость программным путем - не давать клиенту полнофункционирующей версии до тех пор, пока не произойдет оплата по факту.
Прошу прощения за форму, но очень необходимо. Кто может, поделитесь опытом как заставить клиента ПОДПИСАТЬ АКТ о приемке? На моем веку таких актов подписано не было. То есть, клиент либо просто отказывался, либо тянул резину, ссылаясь на выдуманные недочеты и необходимые изменения.
Информационные технологиии способствуют только мировому обнищанию и ни чему более. То, что реально движет жизнь - это производство, сельское хозяйство и топливно-энергетический комплекс. То, для чего сейчас в основном используются информационные технологии - это entertainment. Информационные технологии в производстве - это "о" малое от того, что дает индустрия развлечений.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
Далее. Строгая типизация просто необходима. 30-летний опыт показывает, что она - в момент компиляции обнаруживает большинство ошибок. Не даром в java добавили generics.
Ничего принципиально нового в Closures нет. Он использовался еще в C как паттерн function callback. Но уже в C++ он стал одним из антипаттернов и заменен более адекватными шаблонами (типа Iterator).
Я согласен с Вами, что основная задача groovy - удобство и скорость программирования. Однако удобство и правильность - разные зачастую несовместимые понятия. Это как искусство и коммерция. Программирование, шаблоны, ООП и языки выросли из философских соображений, нежели из соображений удобства, и имеют определенную идею. Гослинг, разработавший Java - идейный человек, а разработчики groovy - комерсанты, завлекающие разработчиков удобством.
HashMap map = new HashMap([key1: "value1", key2: "value2"])
Я так понимаю, что это транслируется в код, который сначала делает LinkedHashMap, а потом из нее HashMap ;)
Умолчания - для молчунов. Вся документация по groovy - это сборник рецептов и враперов для уже существующих api. Никакой формализации, никакой структуры. Словом, помойка для удовлетворения сиюминутных потребностей. Еще раз повторяю, что closures - абсурд. Не понимаю, чем он лучше функционального подхода? В чем философия Collection.each() ? Сама коллекция не имеет свойства обходить свои элементы и делать с ними что-то, пришедшее извне. И не нужно ее учить это делать при помощи closures. Коллекция - для хранения элементов, не более.
Ответы на эти вопросы остаются за кадром и не ясны из контекста. В итоге язык усложняется и обрастает ненужными конструкциями и допущениями. А это возврат на 30 лет к PL/M (думаю, молодые программисты даже не знают что это такое). Все последущие языки эволюционировали в сторону упрощения, то есть при помощи минимальной функциональности и простоты покрыть максимальный объем задач. А вовсе не как сократить количество символов в программе. В итоге был найден определенный компромисс, который имеют все структурные языки. Функциональность расширялась за счет подключаемых библиотек или ООП.
Скриптовые языки типа groovy не являются структурными ибо служат для написания сценариев в уже существующей архитектуре и не более того. Писать что-либо серьезное на groovy будет большой ошибкой.
final String[] mapConst = {"key1","value1","key2","value2" };
Map map = new HashMap();
for ( int i = 0; i < mapConst.length; i+=2 )
map.put( mapConst[i], mapConst[i+1] );
При этом не уродуется язык, а функциональность расширяется за счет собственно функций.
final String[] animals = {"lion", "tiger", "bear"};
for ( String a : animals )
System.out.println( a );
Тем, что проста, понятна, последовательна, легко отлаживаема и выразима на любом алгоритмическом языке? К чему извраты вроде code injection в коллекцию объектов с абстрактным итератором? Как Вы будете пошагово отлаживать свой код, если надо сделать более сложные вещи, нежели вывод объекта? Closures в Java - зло! Java не нужны новые идеи - она самодостаточна.
А проблема в том, что вы не понимаете разницы между алгоритмическими и скриптовыми языками и цели их использования. Декларативное программирование и скриптовые языки хороши там, где кончается архитектура и начинаются прикладные задачи, типа определения бизнес правил и написания сценариев. А весь используемый функционал имплементируется фреймворком более низкого уровня, написанном на нормальном языке типа Java или C/C++.
Mills says that this work, which he terms "Classical Quantum Mechanics", is entirely based on classical physics and special relativity, rejecting quantum theory.
Говоря о состояниях электрона в атоме водорода ниже нулевого уровня, аффтар оказывается не использует квантовую механику, а пользуется все той же классической физикой. Дальше смотреть будем?
Mills says that the electron is an extended particle which in free space is a flat disk of spinning charge.
А завтра он скажет, что Земля - тоже диск.
The Grand Unified Theory of Classical Quantum Mechanics, which he distributes electronically... Superconductivity... Dark matter... The accelerating expansion of the universe...
Обязательно любая новая теория должна объяснить сразу все.
hydrino in 1991 to explain the excess heat reported in 1989 by cold fusion experimentalists
...и присосаться в наиболее скандальных местах, чтобы быть замеченой.
В наш век, век глобальных дезинформационных технологий, без критики просто не обойтись ;)
Кстати, ничего особо положительного в открытости Java я не вижу. Студенты-гнушники превратят ее в большую помойку, полностью разрушая идейность и стройность языка и платформы. Ради получения выгоды от сокращения двух строчек кода в язык встраиваются жуткие рудиментарные конструкции, пришедшие из скриптовых процессоров (посмотрите полный список proposals к Java 7).
Радикальные изменения затронут также и саму VM. Java все больше будут привязывать к платформе GNU, возникнут различные форки проекта, и в результате один и то же софт больше не будет "write once, run everywhere".
А вообще, купите звуковушку с hardware mixing типа Creative, и не парьтесь с этим PA!
Более того, в информационных технологиях судья как правило ничего не понимает, а посему доказать факт выполненной работы становится невозможным. Вот если бы вы строили дом - это другое дело. С другой стороны, в информатике всегда есть возможность восстановить справедливость программным путем - не давать клиенту полнофункционирующей версии до тех пор, пока не произойдет оплата по факту.
Прошу прощения за форму, но очень необходимо. Кто может, поделитесь опытом как заставить клиента ПОДПИСАТЬ АКТ о приемке? На моем веку таких актов подписано не было. То есть, клиент либо просто отказывался, либо тянул резину, ссылаясь на выдуманные недочеты и необходимые изменения.