Блин, у всех mp3, которые я слышал, завалены басы. Никакими эквалайзерами не выправляется. Глубокие наушники немного спасают ситуацию, но не сильно. Вот старый дисковый Sony Walkman умел воспроизводить музыку. А деградация началась, как я услышал первый iPod. Эта хрень могла делать все, кроме своего основного предназначения. Хотя 90% населения звук побарабану - Диму Билана можно слушать на чем угодно.
Под словосочетанием "один-к-разным" Вы подразумеваете наследование.
Посмотрите как, например, наследование реализовано в JPA:
http://www.jpox.org/docs/1_2/jpa_orm/inheritance.html
Два основных принципа: все в одной таблице, либо отдельная таблица на класс.
Численно оптимальность подхода выражается в человекочасах, затраченных на решение. Оно включает не только написание кода, но и архитектурное проектирование, отладку и последующее сопровождение (другими программистами). Вполне вероятно, что начиная с комплексных задач средней сложности, Ваш подход перестанет быть оптимальным. Проект погрязнет в ошибках, программисты, пришедшие в проект не будут понимать код других... можно брать лопату и хоронить.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
Ну и в чем смысл 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!
Не знаю как в России, а в Европе контент сайта можно защитить авторским правом (а также программу и базу данных). Для этого есть специальный реестр. Думаю, сначала нужно выявить фирму, стоящую за сайтом. Затем нужно нанять юриста, который приготовит материалы, доказывающие копию, а также подаст заявку на защиту контента авторским правом (если это возможно). После этого необходимо написать грозное письмо с просьбой убрать копирайтные материалы с другого сайта. Если владельца выявить не удается, нужно действовать через провайдера.
Посмотрите как, например, наследование реализовано в JPA:
http://www.jpox.org/docs/1_2/jpa_orm/inheritance.html
Два основных принципа: все в одной таблице, либо отдельная таблица на класс.
Оптимальным, может быть, для написание серверной вебстранички одним программистом.
Далее. Строгая типизация просто необходима. 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!