powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Java [игнор отключен] [закрыт для гостей] / Перспективы развития java как языка...
25 сообщений из 82, страница 2 из 4
Перспективы развития java как языка...
    #34151702
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton...написал...
1. Согласен.
2. Не согласен. Имхо он только читабельность кода затрудняет. Мое личное мнение, как человека, перешедшего на Яву после 4 лет работы чисто на Дельфе и 2 года проработавшего в режиме переключения между одной и второй.
3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью.
4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред.
5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение.
6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно.
7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно?
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151730
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зашедший4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред.

Мне кажется просто был плохой пример. Возможно хотелось что-то типа using из C#. Первый шаг - интерфейс Closable уже сделан.

Зашедший6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно.

Угу, дотнетчики к примеру тоже не понимают зачем они нужны.

Зашедший7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно?
Есть неплохие сторонние реализации включать эту фичу в core Java смысла действительно нет.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151762
Usual Suspect
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Перспектив много: http://www.javalobby.org/java/forums/t84854.html http://cafe.elharo.com/java/ratjava/
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151773
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зашедший
3. А зачем нужен "второй С++"? С управлением ссылками и прочим? Ява, собственно, задумана как абстракция, позволяющая минимизировать управление памятью.

Я думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения.


4. За такой "синтаксис" во многих местах отрывают разное . "Глушение" ошибок допустимо только на этапе отладки. Во всех продакшн-версиях они должны или отсылаться наверх по стеку, или обрабатываться. Делать один из грубейших приемов "плохого программирования" частью языка - бред.

Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ?


5. Не согласен. Это нововведение противоречит всей концепции Явы как языка, имеющего в методах лишь одно возвращаемое значение.

С такой "тягой" к концепциям, обсуждать перспективы довольно сложно, коллега.


6. "Разборка бинарников" - совсем не главная область применения, и вводить эту искуственную (по отношению к концепции) конструкцию для угоды 0,00..1% программистов - неправильно.

Согласен. Выглядит несколько искусственно. Наверное я попал в этот крохотый процент программистов. Просто, если-бы у меня был выбор методик парсинга бинарных файлов, имеющих характерную структурность (заголовки, теги, таблицы), я бы выбрал наиболее лёгкий с точки зрения описания (декларация структуры атомов), и быстрый с позиций диска (блочные операции ввода вывода). Наверное меня поддержат программисты С++, которые аналогичные задачи выполняли довольно часто.


7. Да, действительно спорный вопрос. Я, например, категорически против. Да и разве аннотаций недостаточно?
Ну.. может вы не будете так категоричны. Давайте подождем, что скажут по этому поводу другие мемберы.

Большое спасибо за интерес к проблеме и за критику.

С уважением
Lord Mayton
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151800
Usual Suspect
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
maytonЯ думал об этом. Однако оптимизация использвания кучи не дает мне покоя. Возможно, у меня сейчас не хватает аргументов. Однако, через некоторое время, если топик не заглохнет я приведу несколько доводов в пользу этого предложения.Гондурас беспокоит? Говорят, если не думать об этом, помогает. Еще говорят весь мир пишет на жабе и не особо парится насчет уборщика мусора, а поди ж ты, есть люди, которым вечно все не так и не эдак.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151822
smbdy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Код: plaintext
mayton 
переходи на C# ;)
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151830
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
smbdy
Код: plaintext
mayton 
переходи на C# ;)
Это не есть выход. Во первых я и так делаю проджекты на обоих языках. А во вторых мне не безразличена эволюция Java.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151858
Фотография ррмяф
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Меня радует то, что в Java нет операций над указателями. И не нужны они ни в каком виде.

При невозможности пустить ошибку вверх - нужно хотя бы логировать ошибку в файл и выдавать в результате функции ошибку. Хотя меня идеология thrown невероятно радует. Это просто щастье (после кое-каких других языков).

Препроцессор, встроенный в язык - в первую очередь он снизит читабельность программ. А плюсы у него крайне сомнительные - для Java, разумеется.


А вкусностей больше не хочется. Лишь бы работало стабильно и быстро.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151905
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[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 - это нечто. ТАК ДЕЛАТЬ НЕЛЬЗЯ! Никогда. По меткой аналогии Блоха (?) - это тоже самое, что отключить пожарную сигнализацию, чтобы не мешала спать (по памяти и чуть поправлено).
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34151906
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot mayton
Как вы будете поступать, если "наверх" ничего нельзя отослать? Т.е. метод базового интерфейса декларирован, как "не-throws" ?
[/quot]
Ну, я уже сказал про исключения. Вариантов много - кинуть assertion, кинуть не проверяемое исключение времени исполнения. Как минимум - вывод сообщения в протокол работы.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34152672
NotGonnaGetUs
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton 1. Мне-бы очень хотелось видеть ...

5. Out-параметры в атомах.


6. Классы-структуры.

7. Наличие препроцессора . Ну.. здесь вопрос очень сложен идеологически. Поэтому я готов слушать контраргументы.


Вместо out параметров и структур хочу кортежи.

Для возвращаемых значений, ака
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
 public   int  *  int  evaluate() {
      return  ( 5 ,  7 );
}


 int  a;
 int  b;

(a, b) = evaluate();


Для паттерн матчинг, ака
Код: plaintext
1.
2.
3.
4.
5.
6.
 public   void  evaluate( int  a,  int  b) {
    match (a, b) {
           |( 5 , _) =>  ...;
           |(_, b) where (b >  5 ) => ...;
   }
}

а так же удобные методы для работы с листами, как это сделано во многих скриптовых и функциональных языках.

Но в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :)

А вместо препроцессора - макросы :)

Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34153573
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Leonidv[quot mayton]....[/quote]
3. java.lang.ref

Я сначала понял, что mayton про некое подобие "арифметики указателей" говорил. Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :)
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34153833
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Зашедший Хотя если он имел в виду просто "слабые ссылки" этц - тогда это просто незнание языка :)
Очень на то похоже
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34153982
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NotGonnaGetUsНо в приницпе, всё это появится ввиде поддержки скриптовых языков в java 7. В том же groovy это почти есть :)

А вместо препроцессора - макросы :)

Смешной язык получился бы. Думаю после появления замыканий в 7 версии, появятся и остальные фичи.

Поддерживаю вас.

Не могли-бы дать ссылочку на анонс возможностей семёрки? (Искать неохота)
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34154038
Фотография hinotf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
например: http://javatech.info/node/151

Nai tiruvantel ar varyuvantel i Valar tieyanna nu vilya
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34154126
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Не отказался бы от компилятора Nemerle в байткод.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34154251
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hinotfнапример: http://javatech.info/node/151
У меня - ссылка не работает. Правый фрейм - пустой.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34154441
Фотография hinotf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
процитирую:

Компания 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
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34155291
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hinotf
...Выделение методов доступа к полям (getters и setters);...

...Новый интерфейс для доступа к специфическим для файловой системы атрибутам и сервисный интерфейс для реализации подключаемых реализаций файловых систем;
API для асинхронных операций над сокетами и файлами;...

Большое спасибо за экскурс. Про геттеры и сеттеры хотел упомянуть, да как-то забылось.

Жду с нетерпением новостей.

C уважением
Lord Mayton
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34159398
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Леонид!

Извините, что сразу не ответил. Был занят.

Leonidv
Ну, я уже сказал про исключения. Вариантов много - кинуть assertion,
кинуть не проверяемое исключение времени исполнения. Как минимум - вывод
сообщения в протокол работы.


Все эти варианты я использовал. Но на каком-то этапе они мне были не нужны, так как
включались в код, который финализировал работу прикладной системы.

Leonidov
Плюс в очень редко используемой функциональности. Мне не сложно написать input.readbyte();.
Эта фишка, как я понимаю, не вписывается в концепцию Java. Тут идет почти прямая работа с памятью.


Я не считаю такое ограничение принципиальным. Косвенно - работа с памятью всё-же идет через
механизмы блочных операций java.io или java.nio. Для полноценной работы с классами-структурами нехватает
маленького связующего звена - маппинга фрагмета памяти в экземпляр объекта, содержимое которго от
нас надежно скрыто за интерфейсом атомов (полей экземпляра). Это ограничение я считаю избыточным.

И еще раз по поводу идеологии . В одном из топиков я это говорил - "если есть возможность
сократить и упростить код - программист это сделает", не взирая ни на какие идеологические ценности.
Практика ставит всё на свои места!

Эту истину я усвоил, поработав несколько лет в секторе внедрения и поддержки ПО.

На моих глазах академичные решения рушились и их место занимали простые, подобно АК-47 но провернные
временем механизмы.

Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта?
Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде,
которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и
УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию?

Почему идеология вызывет у меня так много нареканий?

Почему нельзя вернуть из функции unsigned long? Почему нельзя просто
просуммировать байты? Почему коллекция ArrayList<myObject> жрет столько-же памяти,
сколько и ArrayList<Object> ? Почему swing-приложение вызывает бесконечные жалобы пользователей
на тормознутость GDI? Почему файловые блокировки реализованы не средствами ОС, а средствами платформы?

И этот поток "почему" у меня - бесконечен!

Скажу честно. 99% исходного программного кода на Java, которые я внедряю,
НИКТО НИКОГДА НЕ УВИДИТ, кроме меня самого, моих коллег. Так-что МНЕ НЕКОМУ ПОКАЗАТЬ
КРАСОТУ ИЛИ ИДЕОЛОГИЧЕСКУЮ ЦЕЛОСТОСТЬ РЕШЕНИЙ!

У меня - другие цели.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34161128
Leonidv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический.
И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя.

Я как-то раз работал с библиотечкой, JPcap, явно написанной настоящим программистом на C. И понял, почему многие C-программисты терпеть не могу Java. Так что все о чем вы говорите, я могу понять. Только принимать не хочу :)
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34161340
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mayton
Почему нельзя вернуть из функции unsigned long?
Почему нельзя просто просуммировать байты?
Почему коллекция ArrayList<myObject> жрет столько-же памяти, сколько и ArrayList<Object> ?
Почему swing-приложение вызывает бесконечные жалобы пользователей на тормознутость GDI?
Почему файловые блокировки реализованы не средствами ОС, а средствами платформы?

Не знаю, и причин особых не вижу.
А что мешает?
Лист, хранящий набор указателей , независимо от типов объектов, на которые указывают эти самые указатели, будет иметь один и тот же размер. По-моему очевидно.
Потому что оно работает на всех ОС, и работает одинаково .
См. предыдущую строку.
Уважаемый Mayton, позвольте Вам напомнить, что Ява - не язык для написания драйверов, не язык для разбора огромных бинарников, не язык для создания операционных систем и еще много чего "не". Это язык, который изначально создавался для распределенных гетерогенных сетевых приложений, кроссплатформенности и мультимедии. Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34162461
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LeonidvУ меня к вам тоже возник вопрос "Почему вы пишите на идеологической правильной, но такой неудобной Java" ;) Впрочем, он риторический.

Да. Вопрос риторический. И я не хочу, чтобы вы меня причисляли к противникам Java. Да. От меня часто исходит критика. Это моё кредо. Но лучше-уж оценивать технологию со стороны, глазом инженера с двумя высшимы техническими, чем испытывать щенячий восторг и раболепие перед софтверным гигантом, посещая семинары, больше похожие на маркетинг-планы "пирамидальных сект", где тебя прорабатывают, как будушего партнера.

И я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию .

Я-же в форуме взял на карандаш некоторые недостатки языка и платформы которые ИМХО следует устранить в новых версиях. Как видите, это вызвало бурную реакцию зашедших коллег по топику. Ну.. что-ж. Ничего. Пускай поволнуются.

А мы подождём седьмого релиза.


И еще. Не совсем понял. Если известна и хорошо описана структура файла, то написать код считывающий его - ну это работа не на месяц. Максимум неделя.

По поводу файла. Расскажу. Спецификация его зародилась в недрах одного закрытого предприятия. В принципе её как таковой-не было. Были скупые инструкции по работе с древним софтом и несколько запутанных исходников на С++, которые мы добыли каким-то чудом.
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34162462
abcdcdcd
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mayton
Почему мой разработчкик-джавист Сергей провозился с парсингом графического файла целый месяц и отодвинул сроки сдачи проекта?
Ответ прост! Он пытался адаптировать С++-овский код, который работал со структурами (struct) и битовыми полями (bitfields) к той среде,
которая эти структуры НЕ ПОНИМАЛА! Более того, когда портирование было закончено, красивый некогда исходник УСЛОЖНИЛСЯ и
УВЕЛИЛИЛСЯ в размерах в три раза! Это что? Плата за идеологию?
Потому что нужно учиться пользоваться инструментом. Вот: http://proklondike.com/java_knudsen_2dgraphics.html хотя бы
Почему идеология вызывет у меня так много нареканий?
Пишите на C++, кто вас заставляет пользоваться неудобным инструментом?? "Партия и правительство"?

Хочется "эффективности и скорости в разборе бинарников" - вэлком в ассемблер. А как по мне - если в Яву добавят по просьбам особо "умных" товарищей не-кроссплатформенные вещи типо разбора файлов в структуры и т.п., и при написании очередной софтины мне придется делать отдельные брэнчи под те 4-5 ОС, под которые она должна работать... честно говоря, рука сама потянется к пистолету.Имхо бояться нечего, ТАМ люди вменяемые, все "достоинства" C++ вкусили еще 10 лет назад. Наоборот, сейчас все движется в сторону функциональщины, и в жабу хотят всунуть все карринги, замыкания и проч. которыми и в других-то языках мало кто пользуется из-за сложности и жабе они дадут мало пользы
...
Рейтинг: 0 / 0
Перспективы развития java как языка...
    #34164155
Зашедший
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
maytonИ я на самом деле не в силах и не вправе убеждать вас в том, плоха Java или хороша. Просто хотелось, чтобы появилость сомнение , что как известно - является ключом к пониманию .
Для интереса, посмотрите как-нибудь структуру использования Явы - для чего и где она юзается. Я лично считаю, что для своего основного применения - создание интернет-приложений и аналога "скриптового языка" (см. использование в Оракле, например) - это лучший инструмент по сочетанию мощности, гибкости и скорости. Большинство же предлагаемых Вами фич - поклоны в сторону работы с бинарниками, всяких синтаксических анализаторов и т.п. С моей точки зрения - очень похоже на требования прикрутить ручку к микроскопу, потому что им гвозди забивать неудобно. А не лучше ли использовать для забивания гвоздей молоток, а? А микроскоп для того, для чего он придуман?
...
Рейтинг: 0 / 0
25 сообщений из 82, страница 2 из 4
Форумы / Java [игнор отключен] [закрыт для гостей] / Перспективы развития java как языка...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]