|
|
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton...написал... 1. Согласен. 2. Не согласен. Имхо он только читабельность кода затрудняет. Мое личное мнение, как человека, перешедшего на Яву после 4 лет работы чисто на Дельфе и 2 года проработавшего в режиме переключения между одной и второй. 3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью. 4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. 5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение. 6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. 7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 21:14:04 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. Мне кажется просто был плохой пример. Возможно хотелось что-то типа using из C#. Первый шаг - интерфейс Closable уже сделан. Зашедший6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. Угу, дотнетчики к примеру тоже не понимают зачем они нужны. Зашедший7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? Есть неплохие сторонние реализации включать эту фичу в core Java смысла действительно нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 21:50:09 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Перспектив много: http://www.javalobby.org/java/forums/t84854.html http://cafe.elharo.com/java/ratjava/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 22:32:58 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший 3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью. Я думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения. 4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред. Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ? 5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение. С такой "тягой" к концепциям, обсуждать перспективы довольно сложно, коллега. 6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно. Согласен. Выглядит несколько искусственно. Наверное я попал в этот крохотый процент программистов. Просто, если-бы у меня был выбор методик парсинга бинарных файлов, имеющих характерную структурность (заголовки, теги, таблицы), я бы выбрал наиболее лёгкий с точки зрения описания (декларация структуры атомов), и быстрый с позиций диска (блочные операции ввода вывода). Наверное меня поддержат программисты С++, которые аналогичные задачи выполняли довольно часто. 7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно? Ну.. может вы не будете так категоричны. Давайте подождем, что скажут по этому поводу другие мемберы. Большое спасибо за интерес к проблеме и за критику. С уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 22:44:13 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonЯ думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения.Гондурас беспокоит? Говорят, если не думать об этом, помогает. Еще говорят весь мир пишет на жабе и не особо парится насчет уборщика мусора, а поди ж ты, есть люди, которым вечно все не так и не эдак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:17:45 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:32:16 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
smbdy Код: plaintext Это не есть выход. Во первых я и так делаю проджекты на обоих языках. А во вторых мне не безразличена эволюция Java. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2006, 23:39:19 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Меня радует то, что в Java нет операций над указателями. И не нужны они ни в каком виде. При невозможности пустить ошибку вверх - нужно хотя бы логировать ошибку в файл и выдавать в результате функции ошибку. Хотя меня идеология thrown невероятно радует. Это просто щастье (после кое-каких других языков). Препроцессор, встроенный в язык - в первую очередь он снизит читабельность программ. А плюсы у него крайне сомнительные - для Java, разумеется. А вкусностей больше не хочется. Лишь бы работало стабильно и быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 00:22:48 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
[quot mayton]....[/quote] 1. Не знаю. У меня задач таких не стояло. Поэтому 0. :) 2. Использовал его в течение первух двух или трех лет писания на Delphi. В течение оставшихся 4(5) - может пару раз. Такие фишки как with x do with b do фиг разберешь. Плюс старые IDE (D3-D6) на этом деле подглючивали. 3. java.lang.ref 4. Будем считать, что вы ТАК не писали. Потому как если писали - двойка вам в области работы с исключениями. 5. Скорее нет, чем да. Рефакторинг "Замена данных объектом" или как-то так вам в помощь. 6. Плюс в очень редко используемой функциональности. Мне не сложно написать input.readbyte();. Эта фишка, как я понимаю, не вписывается в концепцию Java. Тут идет почти прямая работа с памятью. 7. Анатоции. Аспектно-ориентированное программирование. NetBeans (?). PS Не обижайтесь, но надо следить за новшествами языка, а не использовать его версию 97-98 года. Это я про 3 и 7. Ну а 4 - это нечто. ТАК ДЕЛАТЬ НЕЛЬЗЯ! Никогда. По меткой аналогии Блоха (?) - это тоже самое, что отключить пожарную сигнализацию, чтобы не мешала спать (по памяти и чуть поправлено). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 01:49:54 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
[quot mayton Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ? [/quot] Ну, я уже сказал про исключения. Вариантов много - кинуть assertion, кинуть не проверяемое исключение времени исполнения. Как минимум - вывод сообщения в протокол работы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 01:53:55 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton 1. Мне-бы очень хотелось видеть ... 5. Out-параметры в атомах. 6. Классы-структуры. 7. Наличие препроцессора . Ну.. здесь вопрос очень сложен идеологически. Поэтому я готов слушать контраргументы. Вместо out параметров и структур хочу кортежи. Для возвращаемых значений, ака Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Для паттерн матчинг, ака Код: plaintext 1. 2. 3. 4. 5. 6. а так же удобные методы для работы с листами, как это сделано во многих скриптовых и функциональных языках. Но в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :) А вместо препроцессора - макросы :) Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 11:06:43 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Leonidv[quot mayton]....[/quote] 3. java.lang.ref Я сначала понял, что mayton про некое подобие "арифметики указателей" говорил. Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 14:14:43 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Зашедший Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :) Очень на то похоже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:06:32 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsНо в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :) А вместо препроцессора - макросы :) Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи. Поддерживаю вас. Не могли-бы дать ссылочку на анонс возможностей семёрки? (Искать неохота) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:36:34 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
например: http://javatech.info/node/151 Nai tiruvantel ar varyuvantel i Valar tieyanna nu vilya ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 15:47:19 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Не отказался бы от компилятора Nemerle в байткод. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 16:05:14 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
hinotfнапример: http://javatech.info/node/151 У меня - ссылка не работает. Правый фрейм - пустой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 16:31:18 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
процитирую: Компания Sun через своих инсайдеров продолжает делиться информацией о следующих выпусках настольной Java платформы, а именно – Java SE 7. Данный материал является логическим продолжением ранее опубликованной заметки. Ниже представлена сводка изменений и дополнений в к базовому API и неязыковой функциональности, которые планируются в данный момент. Естественно, что к предполагаемой дате выхода Java SE 7 (2008 год), многое может измениться. Развитие модульности JSR 277 JavaTM Module System – спецификация предусматривает разработку замены формату JAR, и будет включать в себя такие компоненты: новый формат поставки (т.н. Java Module), предназначенный для распространения Java кода, связанных с ним ресурсов и метаданных: поддержка версий: репозиторий для хранения модулей на пользовательской станции с поддержкой изолированного хранения пакетов разных версий: поддержка в загрузчиках классов и приложений поиска, загрузки и проверки целостности модулей: набор средств для работы с модулями и репозиторием. Поддержка других языков программирования JSR 192 Supporting Dynamically Typed Languages on the JavaTM Platform – спецификация предусматривает добавление к набору инструкций JVM инструкции invokedynamic, ответственную за вызов метода с неизвестными во время компиляции типом возвращаемого значения и типами параметров, что облегчит создание компиляторов для динамически типизируемых языков, таких как Ruby и Python. Добавление нескольких реализаций динамических языков – к 2008 году (времени выхода платформы), разработчики надеются на создание (адаптацию) нескольких реализаций динамических языков, таких как JRuby, Jython, Beanshell. Возможно, некоторые из них будут включены в базовую поставку. Swing JSR 295 Beans Binding – спецификация предусматривает создание API, ответственного за синхронизацию свойств разных JavaBeans, в том числе с разными типами (конверсия и валидация). JSR 296 Swing Application Framework – создание базового каркаса приложения на Swing, отвечающего за следующие, общие для всех настольных приложений вопросы: Выделение жизненного цикла приложения (фазы начальной загрузки и завершения работы); Поддержка локализации ресурсов. Также ресурсы могут быть специфичными для платформы или «марки» приложения; Хранение сессии пользователя между сеансами; Поддержка асинхронного выполнения действий с индикацией состояния. JSR 303 Bean Validation – универсальный API для валидации данных в программе. Информация для валидирования задается с помощью аннотаций или XML дескрипторов. Прочее JSR 220 Java Persistence Architecture – в Java SE 7 планируется включить разработанный группой экспертов по EJB persistence API, значительно облегчающий работу с реляционными БД из объектно-ориентированного кода. JSR 260 Javadoc Tag Technology Update – различные дополнения к JavaDoc, такие, как: Категоризация методов и полей по типу использования; Семантический индекс классов и пакетов; Отделение статических, фабричных и устаревших методов от обычных (ординарных); Выделение методов доступа к полям (getters и setters); Комбинирование и разделение информации в т.н. views; Внедрение примеров и общих вариантов использования. JSR 255 Java Management Extensions Specification, version 2.0 – эволюционное развитие JMX и JMX Remote API, направленное на облегчение использования и добавление новых полезных свойств. Раннее планировалось включить его в состав Java SE 6. Наиболее интересными изменениями являются: Использование generics в JMX API; Использование аннотаций для описания MBeans; Возможность мониторинга сложных типом (за счет использования generics); Поддержка каскадных (federated) серверов MBeans. JSR 262 Web Services Connector for JavaTM Management Extensions (JMXTM) Agents – позволяет организовать доступ к JXM API с помощью web services. JSR 203 More New I/O APIs for the JavaTM Platform (NIO 2) – расширения существующего java.nio API следующими функциями: Новый интерфейс для доступа к специфическим для файловой системы атрибутам и сервисный интерфейс для реализации подключаемых реализаций файловых систем; API для асинхронных операций над сокетами и файлами; Завершение реализации функциональности из JSR 51(поддержка связывания, настройки опций и multicast datagrams). Часть из вышеперечисленных спецификаций планировалась к включению в Java SE 5 и Java SE 6. Будем надеяться, что у команды, разрабатывающей 7-й релиз Java SE, хватит ресурсов для реализации всего заявленного качественно и в срок. Nai tiruvantel ar varyuvantel i Valar tieyanna nu vilya ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.11.2006, 17:16:08 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
hinotf ...Выделение методов доступа к полям (getters и setters);... ...Новый интерфейс для доступа к специфическим для файловой системы атрибутам и сервисный интерфейс для реализации подключаемых реализаций файловых систем; API для асинхронных операций над сокетами и файлами;... Большое спасибо за экскурс. Про геттеры и сеттеры хотел упомянуть, да как-то забылось. Жду с нетерпением новостей. C уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.11.2006, 13:46:05 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
Леонид! Извините, что сразу не ответил. Был занят. Leonidv Ну, я уже сказал про исключения. Вариантов много - кинуть assertion, кинуть не проверяемое исключение времени исполнения. Как минимум - вывод сообщения в протокол работы. Все эти варианты я использовал. Но на каком-то этапе они мне были не нужны, так как включались в код, который финализировал работу прикладной системы. Leonidov Плюс в очень редко используемой функциональности. Мне не сложно написать input.readbyte();. Эта фишка, как я понимаю, не вписывается в концепцию Java. Тут идет почти прямая работа с памятью. Я не считаю такое ограничение принципиальным. Косвенно - работа с памятью всё-же идет через механизмы блочных операций java.io или java.nio. Для полноценной работы с классами-структурами нехватает маленького связующего звена - маппинга фрагмета памяти в экземпляр объекта, содержимое которго от нас надежно скрыто за интерфейсом атомов (полей экземпляра). Это ограничение я считаю избыточным. И еще раз по поводу идеологии . В одном из топиков я это говорил - "если есть возможность сократить и упростить код - программист это сделает", не взирая ни на какие идеологические ценности. Практика ставит всё на свои места! Эту истину я усвоил, поработав несколько лет в секторе внедрения и поддержки ПО. На моих глазах академичные решения рушились и их место занимали простые, подобно АК-47 но провернные временем механизмы. Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта? Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде, которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию? Почему идеология вызывет у меня так много нареканий? Почему нельзя вернуть из функции unsigned long? Почему нельзя просто просуммировать байты? Почему коллекция ArrayList<myObject> жрет столько-же памяти, сколько и ArrayList<Object> ? Почему swing-приложение вызывает бесконечные жалобы пользователей на тормознутость GDI? Почему файловые блокировки реализованы не средствами ОС, а средствами платформы? И этот поток "почему" у меня - бесконечен! Скажу честно. 99% исходного программного кода на Java, которые я внедряю, НИКТО НИКОГДА НЕ УВИДИТ, кроме меня самого, моих коллег. Так-что МНЕ НЕКОМУ ПОКАЗАТЬ КРАСОТУ ИЛИ ИДЕОЛОГИЧЕСКУЮ ЦЕЛОСТОСТЬ РЕШЕНИЙ! У меня - другие цели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 01:47:58 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
У меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический. И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя. Я как-то раз работал с библиотечкой, JPcap, явно написанной настоящим программистом на C. И понял, почему многие C-программисты терпеть не могу Java. Так что все о чем вы говорите, я могу понять. Только принимать не хочу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 15:24:34 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton Почему нельзя вернуть из функции unsigned long? Почему нельзя просто просуммировать байты? Почему коллекция ArrayList<myObject> жрет столько-же памяти, сколько и ArrayList<Object> ? Почему swing-приложение вызывает бесконечные жалобы пользователей на тормознутость GDI? Почему файловые блокировки реализованы не средствами ОС, а средствами платформы? Не знаю, и причин особых не вижу. А что мешает? Лист, хранящий набор указателей , независимо от типов объектов, на которые указывают эти самые указатели, будет иметь один и тот же размер. По-моему очевидно. Потому что оно работает на всех ОС, и работает одинаково . См. предыдущую строку. Уважаемый Mayton, позвольте Вам напомнить, что Ява - не язык для написания драйверов, не язык для разбора огромных бинарников, не язык для создания операционных систем и еще много чего "не". Это язык, который изначально создавался для распределенных гетерогенных сетевых приложений, кроссплатформенности и мультимедии. Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 16:05:20 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
LeonidvУ меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический. Да. Вопрос риторический. И я не хочу, чтобы вы меня причисляли к противникам Java. Да. От меня часто исходит критика. Это моё кредо. Но лучше-уж оценивать технологию со стороны, глазом инженера с двумя высшимы техническими, чем испытывать щенячий восторг и раболепие перед софтверным гигантом, посещая семинары, больше похожие на маркетинг-планы "пирамидальных сект", где тебя прорабатывают, как будушего партнера. И я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию . Я-же в форуме взял на карандаш некоторые недостатки языка и платформы которые ИМХО следует устранить в новых версиях. Как видите, это вызвало бурную реакцию зашедших коллег по топику. Ну.. что-ж. Ничего. Пускай поволнуются. А мы подождём седьмого релиза. И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя. По поводу файла. Расскажу. Спецификация его зародилась в недрах одного закрытого предприятия. В принципе её как таковой-не было. Были скупые инструкции по работе с древним софтом и несколько запутанных исходников на С++, которые мы добыли каким-то чудом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 23:32:17 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
mayton Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта? Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде, которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию? Потому что нужно учиться пользоваться инструментом. Вот: http://proklondike.com/java_knudsen_2dgraphics.html хотя бы Почему идеология вызывет у меня так много нареканий? Пишите на C++, кто вас заставляет пользоваться неудобным инструментом?? "Партия и правительство"? Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету.Имхо бояться нечего, ТАМ люди вменяемые, все "достоинства" C++ вкусили еще 10 лет назад. Наоборот, сейчас все движется в сторону функциональщины, и в жабу хотят всунуть все карринги, замыкания и проч. которыми и в других-то языках мало кто пользуется из-за сложности и жабе они дадут мало пользы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.11.2006, 23:32:31 |
|
||
|
Перспективы развития java как языка...
|
|||
|---|---|---|---|
|
#18+
maytonИ я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию . Для интереса, посмотрите как-нибудь структуру использования Явы - для чего и где она юзается. Я лично считаю, что для своего основного применения - создание интернет-приложений и аналога "скриптового языка" (см. использование в Оракле, например) - это лучший инструмент по сочетанию мощности, гибкости и скорости. Большинство же предлагаемых Вами фич - поклоны в сторону работы с бинарниками, всяких синтаксических анализаторов и т.п. С моей точки зрения - очень похоже на требования прикрутить ручку к микроскопу, потому что им гвозди забивать неудобно. А не лучше ли использовать для забивания гвоздей молоток, а? А микроскоп для того, для чего он придуман? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.11.2006, 14:23:57 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=34153982&tid=2147162]: |
0ms |
get settings: |
11ms |
get forum list: |
20ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
59ms |
get topic data: |
17ms |
get forum data: |
4ms |
get page messages: |
94ms |
get tp. blocked users: |
3ms |
| others: | 439ms |
| total: | 657ms |

| 0 / 0 |
