Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Конечно! А как он напишет, что надо всем коллективно с крыши прыгать, сразу бежать на последний этаж.
Java — платформа, которая решает большие бизнес задачи успешно уже многие годы.
Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется.
Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Здравствуйте, XJava, Вы писали:
XJ>Java — платформа, которая решает большие бизнес задачи успешно уже многие годы. XJ>Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется.
XJ>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Кстати, для Java можно писать на Ruby и Python. Вперед использовать красоту!
Здравствуйте, XJava, Вы писали:
XJ>Java — платформа, которая решает большие бизнес задачи успешно уже многие годы.
Потребности постепенно растут, было бы просто отлично, если бы и возможности поспевали за ними. Это как с доходом... сколько бы он ни составлял, его всегда будет мало. Так вот Sun сильно расстраивает в этом отношении... посмотрим, что в Java 7 будет. Дополнительный кол, кажется, JSR-277, и нежелание Sun принять существующие наработки в отношении OSGi.
XJ>Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется.
В Java очень много недостатков, которые ликвидировали в C#, в основном, конечно же, просто с нуля реализовали по уму, на основе опыта общения с граблями других, эта консервативность JCP удручает. Где runtime generic, closures, default immutability, пересмотр JDBC в сторону стройности в отношении Closeable, чтобы аналог C# using был в легкую возможен и в Java... и т.д. и т.п.? И ведь это только минимум, про фичи вроде выведения типов я вообще молчу, хотя бы сделали то, что и ежу уже понятно, что нужно позарез.
Тем не менее в Java есть одно, и как мне кажется, ключевое преимущество (видимо, осозноваемое в Sun, только так я могу оправдать консервативность в отношении ноу-хау в Java): Java является лучшим выбором из языков программирования бизнес-приложений для начинающих и программистов среднего уровня (скажем, до 5 лет активного кодирования), здесь писал почему: Re[8]: [офф] небольшой вопрос по LINQ
— но на определенном уровне начинаешь замечать, что совершаешь холостые действия, без которых можно спокойно обойтись, сменив Java на что-то иное, вроде Scala. Важно, что при этом ты не совершаешь никакой революции в стиле ковбойского наскока, Scala JRE/CLR-компилируема, а потому сохраняются текущие инвестиции. Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность?
XJ>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Например?
Re[5]: Scala, пеар ...
От:
Аноним
Дата:
05.01.08 21:06
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>unkis,
U>>а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
LCR>Функции-как-первоклассные-значения, трейты и миксины, паттерн-матчинг, полноценные параметрические типы, абстрактные типы и типы-мемберы, замыкания (сравни с тем, что предлагают Блох сотоварищи и пошли им емэйл с йадом), туплы, структурные типы, ко- и контр- вариантность, экзистенциальные типы, вьюхи и многое другое. Плюс, всё это посыпано некоторым слоем сахара, чтобы визуально уменьшить количество кода.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>unkis,
U>>>а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
LCR>>Функции-как-первоклассные-значения, трейты и миксины, паттерн-матчинг, полноценные параметрические типы, абстрактные типы и типы-мемберы, замыкания (сравни с тем, что предлагают Блох сотоварищи и пошли им емэйл с йадом), туплы, структурные типы, ко- и контр- вариантность, экзистенциальные типы, вьюхи и многое другое. Плюс, всё это посыпано некоторым слоем сахара, чтобы визуально уменьшить количество кода.
А>Scala тоже не нужен http://creativekarma.com/ee.php/weblog/comments/my_verdict_on_the_scala_language/. Значит и Scala умер. Что остается?
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Вот маленький такой калькулятор, обращаю внимание на функцию eval. По моим субъективным ощущениям, эквивалентный джавовский код будет раза в 4 больше. Плюс появление (анти-)паттерна "визитор".
Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
R>В Java очень много недостатков, <...>
Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться. Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык.
Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать. И что получилось? Да ничего хорошего, на мой взгляд, не получилось. Хотя уверен, что супер профессионалы на этом языке могут писать супер профессионально. Только вот подавляющие большинстов, это программисты, которые могут дров наломать так, что потом эти дрова не в поленницу сложить, не печь засунуть.
Кстати, для меня Java первую очередь элегантный язык. Куда как элегантнее Pascal, Basic, Ruby.
PS Если верить Фаулеру, элегантный и, по сути, мертвый язык — Smalltalk.
Здравствуйте, LeonidV, Вы писали:
LV>Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться.
Неверно. Берите тот же Форт — и вперед. Проще некуда — там даже синтаксиса-то как такового нет.
Улучшения в 1.5 реально позволили писать более надежные программы за счет улучшения работы статической типизации. Ну и сахар типа foreach/autoboxing/varargs тоже очень приятен.
LV>Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык.
??
LV>Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать.
ООП в С++ — это не главный источник сложностей. Даже близко не главный...
Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность?
И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Java синтаксис содержит в два раза меньше ключевых слов чем C# и синтаксически прост как кирпич (если не использовать хард-коре женериксы). Масштабируемость, в плане людей, у java просто отличная. В свое время пришлось поработать и с Perl и с C++ но их жутая сложность при всех их возможностях, сводила производительность в 0. Искусство, искусством, но для написания програм больше годятся ремесленники, чем гении.
Здравствуйте, Trean, Вы писали:
T>Здравствуйте, rsn81, Вы писали:
T>Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность? T>И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Я много раз слышал изложение подобной позиции, и она даже имеет под собой некоторые основания.
Но есть еще один фактор... Рассмотрю его с двух сторон:
Со стороны программиста:
— Примерно лет через 5 плотной работы в программировании у разработчиков происходит изменение в способе думать в момент написания кода. В чем-то это изменение похоже на качественный переход во владении иностранным языком. В начале человек мысленно переводит фразы с родного языка на иностранный, перед тем как их высказать (и обратно). Но потом он начинает думать сразу на новом языке, как на родном. И общеизвестно о том какое влияние оказывает язык, на котором думашь, на способ мышления. Аналогичная ситуация и с языками программирования (только "время погружения" требуется существенно больше). После некоторого порога все решение задачи осмысливается в терминах основного используемого языка. И это так же как и с естественным языком накладывает отпечаток и на принимаемые "программистские решения" (в частности — архитектурные) и отчасти даже на "жизнь вне офиса" (а что вы хотели — думая определенным способом 8 часов в день, не так то просто сразу переключиться). На мой взгляд, использование строго ограниченного, многословного, и принудительно-безопасного языка программирования может быть полезно для начинающих, но с какого-то момента становится "вредно для здоровья". И особенно для развития, загоняя мышление в достаточно узкие рамки. Не всегда программисты это понимают сознательно, но очень многие постепенно начинают чувствовать интуитивно... и это приводит нас ко второй стороне монеты.
С точки зрения работодателя:
— Ситуация на рынке труда нынче такова, что хороших програмимистов не хватает. Это достаточно ценный ресурс. А хорошие программисты часто начинают "капризничать" на тему средств разработки вообще, и языков программирования в частности. И если даже времено их удается "подкупить" высокой зарплатой, и уговорить работать на "не интересном" для них языке, этоа ситуация остается неустойчивой. Их легко могут переманить даже без повышения зарплаты. В резултате, если выбирать для фирмы язык и средсва разработки ориентированные на "новичков" и "обычных слабых разработчиков, которых много", то очень быстро толко такие в фирме и станут "накапливаться". И с другой стороны, если взять инструмент ориентированный на опытных профессионалов "старичков", то сам этот факт начнет притягивать таковых.
Таким образом, язык программирования является не только "инструментом разработки продукта", но и "кадровым фильтром"... и с этим стоит считаться.
Спасибо за интересное мнение. Для меня пока выбор экзотического языка пока неоправданный риск, существует большая вероятность провалить проект по причине отсутствия личного опыта в этой самой "экзотике" и проблемой с поиском кадров (команда очень небольшая), поэтому я стараюсь очень осторожно подходить к выбору платформы, средств. Хотя будь у меня более менее крупная фирма я бы сформировал исследовательскую и "прорывную" группы, чтобы избежать деградации в «Падальщики» Та или иная технология должна достигнуть критической массы в отношении стабильности, качества и успешных применений, без этого использовать ее в production (особенно для заказных проектов, как в моем случае) крайне рискованно.
Здравствуйте, Дм.Григорьев, Вы писали:
LCR>>Вот маленький такой калькулятор, обращаю внимание на функцию eval. По моим субъективным ощущениям, эквивалентный джавовский код будет раза в 4 больше. Плюс появление (анти-)паттерна "визитор".
ДГ>Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
Здравствуйте, mkizub, Вы писали:
ДГ>>Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
M>С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
Имеется в виду pattern matching? Если нет, то в чём отличие?
Здравствуйте, Аноним, Вы писали:
А>Шо делать? Си-шарпать?
Нет, отказаться от синтаксиса. Это же синтаксис ему не понравился. Вот от него и отказаться. В C# тоже со временем мусора образуется дофигища. Это во всех языках происходит. Уж сколько примеров было на моей памяти — PL/I, С++, Perl, PHP, вообще любой язык — начинается как простой и тем привлекает массы, а потом массам начинает не хватать того, сего — и язык пухнет, становится маразматичней и маразматичней.
Надо в консерватории поправить. Надо делать язык под конкретный большой проект, конкретный тип задач. И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
Здравствуйте, mkizub, Вы писали:
M>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
M>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
Все правильно говорит mkizub, только не совсем корректно. В чем человек думает не знаю, предполагаю что все-таки образами. А вот что он думает не линейно, это знаю. За подробностью к Тони Бьюзену.
Здравствуйте, LeonidV, Вы писали:
M>>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
LV>Все правильно говорит mkizub, только не совсем корректно. В чем человек думает не знаю, предполагаю что все-таки образами. А вот что он думает не линейно, это знаю. За подробностью к Тони Бьюзену.
Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом. Так что не правильно он говорит. Когда я продумываю архитектуру программы, в голове у меня с бешеной скоростью носятся всякие варианты использования с потоками управления. Даже в фоновом режиме сознание перебирает массу вариантов с огромной скоростью. Даже если этот "мультик" и имеет что-то общее с графическими образами (хотя на самом деле это больше похоже на некое "шестое чувство"), я бы с удовольствием посмотрел на конкретные инструменты сторонников "не только текстового синтаксиса". Чиста чтобы оценить, на сколько порядков они замедлят мне мыслительный процесс.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом.
Нет, дело не в этом.
Человек думает образами. Образ — это не обязательно картинка. Образ это образ. Символ, понятие. Когда компьютеру подсовывают картинку — он ещё должен понять, что там нарисовано, стол или глаз или буквы. Это называется распознаванием образов, так ведь? Вот этими образами человек и думает. Потом это передаётся в осознавание — в виде слов, кто умеет может в виде картинок и т.п.
Когда математик думает, он думает в образах интегралов, матриц и т.п. Когда врач думает, он тоже думает в образах связанных с болезнями, органами и т.п.
Чтоб компьютер мог автоматизировать умственную деятельность человека — он тоже должен уметь думать в образах. Что и делают компиляторы — они преобразуют текст программы в некое внутреннее представление, и в терминах этого внутреннего представления думает, то есть оптимизирует программу, переводит её на язык для CPU, чтоб тот исполнил программу.
Проблема нынешнего способа программирования в том, что этот набор образов (языка программирования) фиксирован. И фиксирован синтаксисом текста программы. Это звучит бредово, но так и есть — синтаксис, внешнее представление, ограничивает способ "думать" и набор понятий компьютера (компилятора). Фактически, человек точно так-же ограничен своим языком, и освоение новой профессиональной области начинается с изучения терминологии, а уже потом человек тренируется думать в этих новых терминах. Для компьютеров аналогично — поскольку мы тут про яву, то вспомни, сколько времени заняло введение новых фич в яву? Inner классы, да простейшие enum-ы... ГОДЫ. Почему так долго? Изменить один компилятор не тяжело, но кому нужны эти изменения? Нужно изменить все связанные средства программирования, от анализаторов кода и отладчиков до всех этих IDE (эклпису, идею, нетбинс и пр.). Потому как все они связаны между собой синтаксисом. У них разные внутренние представления явовской программы, а между собой они взаимодействуют по стандарту текстового синтаксиса.
Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления". Программирование прямо в семантических понятиях, единых для всех средств программирования. Если ты себе для проекта добавляешь новое понятие — с ним смогут работать все средства программирования... Например, мы вводим в наш набор понятий новую абстракцию "перечислымый тип". Мы её описываем неким способом понятным всем нашим средствам программирования — от редактора до отладчика, всем. Но! Редактор то понимает, что это enum, а вот как его редактировать и отображать — он не знает. И это надо будет редактору описать. Если нужно, а по умолчанию он может использовать некий "универсальный" способ представления (скажем, как в lisp — всё отображается в виде списка). Компилятор будет понимать, что вот тут стоит некий enum, но он не будет знать что с ним делать. Надо ему или рассказать как enum-ы выражаются через известный ему набор понятий (скажем, как в java enum-ы компилируются в классы), либо он должен поддерживаться непосредственно target platform, и надо будет поправить backend компилятора.
Графически-диаграммные средства разработки тоже имеют к этому некое отношение. В том смысле, что отображать программу вы можете как угодно. Она в компьюрете непосредственно в его внутреннем представлении хранится, а отображение/редактирование могут быть любыми. Хочешь — текстом. Хочешь — стрелочки рисуй. Хочешь — в UML диаграммах.
