Здравствуйте, Trean, Вы писали:
T>Здравствуйте, rsn81, Вы писали:
T>Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность? T>И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Я много раз слышал изложение подобной позиции, и она даже имеет под собой некоторые основания.
Но есть еще один фактор... Рассмотрю его с двух сторон:
Со стороны программиста:
— Примерно лет через 5 плотной работы в программировании у разработчиков происходит изменение в способе думать в момент написания кода. В чем-то это изменение похоже на качественный переход во владении иностранным языком. В начале человек мысленно переводит фразы с родного языка на иностранный, перед тем как их высказать (и обратно). Но потом он начинает думать сразу на новом языке, как на родном. И общеизвестно о том какое влияние оказывает язык, на котором думашь, на способ мышления. Аналогичная ситуация и с языками программирования (только "время погружения" требуется существенно больше). После некоторого порога все решение задачи осмысливается в терминах основного используемого языка. И это так же как и с естественным языком накладывает отпечаток и на принимаемые "программистские решения" (в частности — архитектурные) и отчасти даже на "жизнь вне офиса" (а что вы хотели — думая определенным способом 8 часов в день, не так то просто сразу переключиться). На мой взгляд, использование строго ограниченного, многословного, и принудительно-безопасного языка программирования может быть полезно для начинающих, но с какого-то момента становится "вредно для здоровья". И особенно для развития, загоняя мышление в достаточно узкие рамки. Не всегда программисты это понимают сознательно, но очень многие постепенно начинают чувствовать интуитивно... и это приводит нас ко второй стороне монеты.
С точки зрения работодателя:
— Ситуация на рынке труда нынче такова, что хороших програмимистов не хватает. Это достаточно ценный ресурс. А хорошие программисты часто начинают "капризничать" на тему средств разработки вообще, и языков программирования в частности. И если даже времено их удается "подкупить" высокой зарплатой, и уговорить работать на "не интересном" для них языке, этоа ситуация остается неустойчивой. Их легко могут переманить даже без повышения зарплаты. В резултате, если выбирать для фирмы язык и средсва разработки ориентированные на "новичков" и "обычных слабых разработчиков, которых много", то очень быстро толко такие в фирме и станут "накапливаться". И с другой стороны, если взять инструмент ориентированный на опытных профессионалов "старичков", то сам этот факт начнет притягивать таковых.
Таким образом, язык программирования является не только "инструментом разработки продукта", но и "кадровым фильтром"... и с этим стоит считаться.
Здравствуйте, <Аноним>, Вы писали:
А>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>>unkis,
U>>>а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
LCR>>Функции-как-первоклассные-значения, трейты и миксины, паттерн-матчинг, полноценные параметрические типы, абстрактные типы и типы-мемберы, замыкания (сравни с тем, что предлагают Блох сотоварищи и пошли им емэйл с йадом), туплы, структурные типы, ко- и контр- вариантность, экзистенциальные типы, вьюхи и многое другое. Плюс, всё это посыпано некоторым слоем сахара, чтобы визуально уменьшить количество кода.
А>Scala тоже не нужен http://creativekarma.com/ee.php/weblog/comments/my_verdict_on_the_scala_language/. Значит и Scala умер. Что остается?
еще давным давно, Дийкстра описывал программирование на очень популярном в то время PL/1 как управление самолетом у которого на пульте 7000 тумблеров и их количество постоянно растет (много кто слышал об этом языке?).. так и тут, Java эволюционирует как большинство распространенных языков программирования, а именно по басне Сергея Михалкова "Слон-живописец".. но сказать конкретно, какой язык придет ему на смену — покамест рано.. после начала подыхания Java, начнется массовый перевод софта с Java на новую "серебряную пулю" и будут требоваться программеры-полиглоты, которые бедет знать оба языка (новый и Java), то что это будет не Си или Си++ — однозначно, так как в нашем случае языки программирования идут на пути деградации и надо думать, что новый язык еще более изолирует программиста от аппаратуры (а так же даст еще более "мощный" механизм управления памяти, что разработчики GC захлебнутся в слюне с последней мыслью "а почему мы не догадались?!"), снизит требования к его подготовке и даст работу сотне другой тысяч менее грамотных индусов, китайцев и россиян-двоешников.. если увидите такое, то сразу бросайтесь в изучениен, нераздумывая...
p.s.
(сюжет для ненаучно-фантастического романа)
однажды, через сотню лет после смерти последнего видевшего вживую 8 разрядный процессор, какойнибудь программист робко напишет чтонибудь в машинных кодах (ассемлеры тогда уже не будут производиться), покажет окружающим, что его код работает в миллион раз быстрее с той же надежностью и будет распят как еретик и маргинал..
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
Одуреть. Брюс, конечно молодец, но как ни заманали.
Главное, вы мне покажите пример хотябы одного языка, который бы умер имея в интерпрайзе миллионы? В С++ полно неправильного дизайна? Он умер? И Java не умрет. Будет не модна, возможно, но не умрет.
Здравствуйте, rsn81, Вы писали:
RI>>Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо. R>Только в C# их исправляют, а в Java пока не заметно... это и расстраивает.
Здравствуйте, 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>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Например?
R>В Java очень много недостатков, <...>
Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться. Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык.
Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать. И что получилось? Да ничего хорошего, на мой взгляд, не получилось. Хотя уверен, что супер профессионалы на этом языке могут писать супер профессионально. Только вот подавляющие большинстов, это программисты, которые могут дров наломать так, что потом эти дрова не в поленницу сложить, не печь засунуть.
Кстати, для меня Java первую очередь элегантный язык. Куда как элегантнее Pascal, Basic, Ruby.
PS Если верить Фаулеру, элегантный и, по сути, мертвый язык — Smalltalk.
Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность?
И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Java синтаксис содержит в два раза меньше ключевых слов чем C# и синтаксически прост как кирпич (если не использовать хард-коре женериксы). Масштабируемость, в плане людей, у java просто отличная. В свое время пришлось поработать и с Perl и с C++ но их жутая сложность при всех их возможностях, сводила производительность в 0. Искусство, искусством, но для написания програм больше годятся ремесленники, чем гении.
Эккель молодец, все правильно написал. Если хочется сахара, нужно делать новый язык, имея в виду, при этом, что язык — не серебряная пуля, и никакой язык не отменит необходимости разрабатывать интерфейс, архитектуру и алгоритмы.
А>Шо делать? Си-шарпать?
Писать по старинке. Не обязательно использовать весь тот мусор, который понавесят в новых версиях. А то будет нечитабельное гуано как в скале, в которой синтаксический ###### достиг чуть ли высшего предела, судя по приведенным выше примерам.
rsn81,
R>Обратил внимание, что в Scala подчистили маленькие несуразности, которые сейчас исправлены даже в C#, а в Java — нет. К примеру, в отношении порядка инициализации членов класса и вызова родительских конструкторов, как следствие, частичное (но оно стоит того) решение проблемы безопасной инициализации, писал об этом здесь: Re[12]: Virtual member call in constructor. Плохо?
Меня вообще бесит правило, что super должен быть в первой строчке. Из-за этого иногда приходится лепить всякие идиотские методы типа init, а конструкторы оставлять простыми заглушками.
cl-user,
CU>И кто в этом виноват? Если бы javac был открыт и документирован вместе со своим AST-ом с самого начала и "торчал этими потрохам наружу", кто бы стал изобретать велосипеды? Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
Да, а как? Generalized common compiler?
M>>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
CU>И нафиг новый "булшит", если есть AST?
Присоединяюсь к вопросу, ибо по мне стандартизация же должна выполняться в каких-то терминах. Рано или поздно мы должны будем упереться в нечто, что придётся взять за основу и это и будет Самый Базовый Язык. Берём и его стандартизируем (вместе с синтаксисом (пусть он у нас будет чисто числовой) и семантикой, да). И назовём его Java Byte Code. Или BEAM Code. Или MSIL, если угодно. И все компиляторы отныне будут просто преобразователями в этот язык. И сделаем мегакомпилятор этого языка под все платформы, и назовём его JIT compiler.
Здравствуйте, LeonidV, Вы писали:
R>>В Java очень много недостатков, <...> LV>Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться. Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык. LV>Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать. И что получилось? Да ничего хорошего, на мой взгляд, не получилось. Хотя уверен, что супер профессионалы на этом языке могут писать супер профессионально. Только вот подавляющие большинстов, это программисты, которые могут дров наломать так, что потом эти дрова не в поленницу сложить, не печь засунуть.
LV>Кстати, для меня Java первую очередь элегантный язык. Куда как элегантнее Pascal, Basic, Ruby.
LV>PS Если верить Фаулеру, элегантный и, по сути, мертвый язык — Smalltalk.
Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это.
Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык.
Думаю, что j2ee еще продержится не один год, слишком много уже на этой платформе сделано и продолжают делать. Люди готовы платить за яву. Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Имеется в виду pattern matching? Если нет, то в чём отличие?
Если кратко, то примерно так выглядит:
public class Circle extends Figure...;
public class Ball extends Figure...;
public class Triangle extends Figure;
public class Something
{
public void doSomething(Circle circle)
{
System.out.println("Circle!");
}
public void doSomething(Ball ball)
{
System.out.println("Ball!");
}
public void doSomething(Figure fig)
{
System.out.println("A figure!");
}
}
Figure fig=new Ball();
//Самое интересное здесь:new Something().doSomething(fig); //Печатает "Ball!"
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
M>>>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
CU>>И нафиг новый "булшит", если есть AST?
А AST стандартизирован?
LCR>Присоединяюсь к вопросу, ибо по мне стандартизация же должна выполняться в каких-то терминах. Рано или поздно мы должны будем упереться в нечто, что придётся взять за основу и это и будет Самый Базовый Язык. Берём и его стандартизируем (вместе с синтаксисом (пусть он у нас будет чисто числовой) и семантикой, да). И назовём его Java Byte Code. Или BEAM Code. Или MSIL, если угодно. И все компиляторы отныне будут просто преобразователями в этот язык. И сделаем мегакомпилятор этого языка под все платформы, и назовём его JIT compiler.
Не понял вопроса.
Самый Базовый Язык может быть разным. Трансляция из одного языка в другой. Другой может быть C, может MSIL, может ява байткод, или некий абстрактный Самый Базовый Язык. Которых, самых базовых, может быть сколько угодно. И занимается трансляцией backend. А компилятор имеет у себя набор узлов, и может заниматься tree transformation как ему захочется. Он "думает" в этих терминах. А с человеком обменивается информацией через текст, через UML диаграмы, через визуальное представление диалогов и т.п. Ты, наверное, путаешь концепцию представления программы в виде дерева с концепцией компилятора с множеством backend-ов. У такого компилятора есть некое "стандартное" внутреннее представление, в которое преобразуют frontend-ы, и из которого генерируют программы backend-ы. А разница в том, что у GCC и подобных — внутренне представление фиксированное, а при подходе о котором я говорю — это расширяемый набор узлов/понятий.
Например, мы вводим понятие closure. Оно самостоятельное понятие. Но оно может быть преобразовано в другие. Для Java некий плагин/backend к компилятору его преобразует в inner class, для .NET в делегат, для OCaml-овской машины оставит как есть и т.п. Нет некоего стандартного представления в которое преобразует код frontend-ы. Эти определяемые семантические понятия/узлы используются компилятором "как есть", они равноправны. Как человек — у него там сформировано понятие о чём-то (скажем, из области геометрии — точка, линия, фигура) и он его может выразить и на русском, и на английском, и на китайском. Но это понятие не привязано к русскому, английскому или китайскому.
LCR>Короче, какой-то боян. Или нет?
Здравствуйте, Аноним, Вы писали:
А>Шо делать? Си-шарпать?
Нет, отказаться от синтаксиса. Это же синтаксис ему не понравился. Вот от него и отказаться. В C# тоже со временем мусора образуется дофигища. Это во всех языках происходит. Уж сколько примеров было на моей памяти — PL/I, С++, Perl, PHP, вообще любой язык — начинается как простой и тем привлекает массы, а потом массам начинает не хватать того, сего — и язык пухнет, становится маразматичней и маразматичней.
Надо в консерватории поправить. Надо делать язык под конкретный большой проект, конкретный тип задач. И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Написал, отправил, удалил как ошибочное. Ну его нафиг, позориться только. А ты давай конкретные примеры, как ты собираешься формализовывать язык описания семантики. Сказки рассказывать все горазды.
Одну такую сказку пишет Чарльз Симони, под названием Intentional Programming. Про неё мало что известно, хотя статейки нарыть можно — http://c2.com/cgi/wiki?IntentionalProgramming
Другую пишут в JetBrains, под названием MPS. Там претензий намного меньше, но можно попробовать. http://www.jetbrains.com/mps/ Мне у них многое не нравится, в частности они так и не решили проблему с неудобством редактирования, ну и слишком у них на Java всё завязано.
Я делаю SymADE — http://www.symade.org/
Собственно, формализировать семантику не особенно нужно. Нужно сделать стандартный способ представления узлов AST дерева (только не abstract syntax tree, а abstract semantic tree). А семантику задавать через правила преобразования в набор "примитивов", неких стандартных узлов AST. Для простых преобразований сгодится и некий язык, скажем что-то вроде AspectJ. Для более сложных вещей нужно будет писать плагин к компилятору, который будет заниматься трансформацией дерева. Понятно, что дизайн компилятора будет сильно отличаться от обычного, так как в обычных слишком много самантики не задаётся правилами, а вшито в код. Но это можно сделать, в частности, так и делается в вышеприведённых примерах.
Здравствуйте, raydac, Вы писали:
R>после начала подыхания Java, начнется массовый перевод софта с Java на новую "серебряную пулю"
Гы. Scala да Nemerle? =) Кстати, позавчера начал изучать Scala... эээ... в общем, хожу под себя кипятком и бьюсь головой об стену, чего ж я, дурак, раньше за неё не взялся?
unkis,
U>а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
Функции-как-первоклассные-значения, трейты и миксины, паттерн-матчинг, полноценные параметрические типы, абстрактные типы и типы-мемберы, замыкания (сравни с тем, что предлагают Блох сотоварищи и пошли им емэйл с йадом), туплы, структурные типы, ко- и контр- вариантность, экзистенциальные типы, вьюхи и многое другое. Плюс, всё это посыпано некоторым слоем сахара, чтобы визуально уменьшить количество кода.
Вот маленький такой калькулятор, обращаю внимание на функцию eval. По моим субъективным ощущениям, эквивалентный джавовский код будет раза в 4 больше. Плюс появление (анти-)паттерна "визитор".
object Gadts extends Application {
abstract class Term[T]
case class Lit(x: int) extends Term[int]
case class Succ(t: Term[int]) extends Term[int]
case class IsZero(t: Term[int]) extends Term[boolean]
case class If[T](c: Term[boolean],
t1: Term[T],
t2: Term[T]) extends Term[T]
def eval[T](t: Term[T]): T = t match {
case Lit(n) => n
case Succ(u) => eval(u) + 1
case IsZero(u) => eval(u) == 0
case If(c, u1, u2) => eval(if (eval(c)) u1 else u2)
}
Console.println(
// типа "if (1 == 0) 41 else (++41)"
eval(If(IsZero(Lit(1)), Lit(41), Succ(Lit(41)))))
}
Обратил внимание, что в Scala подчистили маленькие несуразности, которые сейчас исправлены даже в C#, а в Java — нет. К примеру, в отношении порядка инициализации членов класса и вызова родительских конструкторов, как следствие, частичное (но оно стоит того) решение проблемы безопасной инициализации, писал об этом здесь: Re[12]: Virtual member call in constructor. Плохо?
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Конечно! А как он напишет, что надо всем коллективно с крыши прыгать, сразу бежать на последний этаж.
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Но ниче жива еще . И даст бог протянет ще не один десяток .
R> R>Читал все эти темы. Все это говорит о том, что C# становится все более и более сложным инструментом, который, с одной стороны, опасен для ньюби, но с другой стороны, предоставляет профессионалам инструмент с более тонкой настройкой, который позволяет делать все намного проще, лаконичнее, интуитивно понятнее.
Чем более сложный язык, тем проще одному опытному программисту написать так, что другой опытный программист его не поймет. В результате получаем developer-locking :)
А "интуитивно-понятней" в данном контексте для меня "хрен-знает-как-но-работает". Я сторонник простых языков. И вещей в целом. И привязанность к как можно более простым вещам у меня идет после книг Раскина, Купера и других. В часности, Купера пишет о любви программистов к сложным вещам. И откуда эта любовь берется. И почему это плохо, тоже пишет.
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
ДГ>Гы. Scala да Nemerle? =) Кстати, позавчера начал изучать Scala... эээ... в общем, хожу под себя кипятком и бьюсь головой об стену, чего ж я, дурак, раньше за неё не взялся?
а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
Здравствуйте, Дм.Григорьев, Вы писали: ДГ>Гы. Scala да Nemerle? =) Кстати, позавчера начал изучать Scala... эээ... в общем, хожу под себя кипятком и бьюсь головой об стену, чего ж я, дурак, раньше за неё не взялся?
Рановато еще пока на мой взгляд... сыроват.
Я вот тоже жду пока "подсохнет", да и на развитие lift поглядываю.
Но в ближайшие пару лет IMHO еще рано.
Re: На Java можно ставить крест
От:
Аноним
Дата:
05.01.08 04:16
Оценка:
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Лучше Лиспать
сейчас такая ситуация с большинством разработчиков, что убери гарбадж коллектор и начнут помирать тысячами (как девелоперы).. так что отката на старые языки ждать не стоит
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Гы. Scala да Nemerle? =) Кстати, позавчера начал изучать Scala... эээ... в общем, хожу под себя кипятком и бьюсь головой об стену, чего ж я, дурак, раньше за неё не взялся?
Аналогично. Но пока играюсь только, все же решил дождаться доведения до ума модуля Scala Development Tools под Eclipse.
Здравствуйте, raydac, Вы писали:
А>>>Шо делать? Си-шарпать? А>>Лучше Лиспать
R>сейчас такая ситуация с большинством разработчиков, что убери гарбадж коллектор и начнут помирать тысячами (как девелоперы).. так что отката на старые языки ждать не стоит
А кто сказал, что в Лиспе нет сборщика мусора? Грубя говоря Лисп это суперсет для Java, C#, C/С++, итд итп.
((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x))))
Re[6]: Scala, пеар ...
От:
Аноним
Дата:
05.01.08 10:02
Оценка:
Здравствуйте, rsn81, Вы писали:
R>Здравствуйте, Lazy Cjow Rhrr, Вы писали:
R>Быстрая сортировка... поражает, насколько код близок к словесному описанию алгоритма в отличие от императивного аналога:
def quicksort(list: List[int]): List[int] = {
R> if (list.length <= 1) list
R> else {
R> val l = list(list.length / 2)
R> quicksort(list filter (l >)) ::: (list filter (l ==)) ::: quicksort(list filter (l <))
R> }
R>}
Вы еще на Haskell не видели
quickSort :: Ord a => a -> a
quickSort [] = []
quickSort (x:xs) = quickSort [y | y <- xs, y < x] ++ [x] ++ quickSort [y | y <- xs, y >= x]
Здравствуйте, <Аноним>, Вы писали:
А>Одуреть. Брюс, конечно молодец, но как ни заманали. А>Главное, вы мне покажите пример хотябы одного языка, который бы умер имея в интерпрайзе миллионы? В С++ полно неправильного дизайна? Он умер? И Java не умрет. Будет не модна, возможно, но не умрет.
Например, прикладное программирование в SAP R/3: язык ABAP/4, в принципе, морально умер (программируя на нем, ошущаешь четко различимый запах разложения), шутка ли, с 80-х годов ничего нового... еще поживет, пока все предприятия у нас не переползут на версию SAP R/3 >= 6.0, там идет на замену Java (а это длительный процесс, ибо миллионы).
По поводу Scala, Nemerle и прочих нишевых языков... думаю, если они полностью и заменят текущих монстров (C++, Java, C#), то очень не скоро, а пока, как и сказал Мартин Одерски:
Scala — это язык общего назначения. Я думаю, что он является альтернативой Java во всех прикладных областях. Большим преимуществом является то, что он делает работу программистов продуктивнее, особенно хороших программистов.
Одна из причин, способных заставить вас обратиться к программированию на Scala, состоит в том, что Scala позволяет увеличить производительность разработчика по сравнению с Java, сохраняя скорость исполнения JVM, существующие инвестиции в Java-код, знания и множество API, имеющихся для JVM. Scala обладает краткостью языков типа Ruby или Python, но при этом статически типизирована, как и Java. Еще одна причина в том, что Scala поставляется с Erlang-подобной библиотекой Actors, которая существенно упрощает параллельное программирование, но работает под JVM.
def quicksort(lst) {
| [] => []
| x :: xs => quicksort($[y | y in xs, y < x]) + [x] + quicksort($[y | y in xs, y >= x])
}
Тоже с комментариями:
def quicksort(lst) { // отсортировать список
| [] => [] // если список пуст, то возвратить пустой список
| head :: tail =>
// если список состоит из головы (head)
// и любого хвоста (tail, от пустого списка, до списка любого размера), то
// отсортировать первый подсписок
quicksort(
$[y | y in tail, y < head]) // элементы которого меньшие, чем голова исходного списка
+ [head] // прибавить к результату список, состоящий из головы исходного списка
+ quicksort( // отсортировать второй подсписок
$[y | y in tail, y >= head]) // элементы которого больше или равны голове исходного списка
}
Java — платформа, которая решает большие бизнес задачи успешно уже многие годы.
Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется.
Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Здравствуйте, XJava, Вы писали:
XJ>Java — платформа, которая решает большие бизнес задачи успешно уже многие годы. XJ>Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется.
XJ>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
Кстати, для Java можно писать на Ruby и Python. Вперед использовать красоту!
Re[5]: Scala, пеар ...
От:
Аноним
Дата:
05.01.08 21:06
Оценка:
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>unkis,
U>>а что в этом языке такого нового, или что в нём есть такое, чего нет в java или C#?
LCR>Функции-как-первоклассные-значения, трейты и миксины, паттерн-матчинг, полноценные параметрические типы, абстрактные типы и типы-мемберы, замыкания (сравни с тем, что предлагают Блох сотоварищи и пошли им емэйл с йадом), туплы, структурные типы, ко- и контр- вариантность, экзистенциальные типы, вьюхи и многое другое. Плюс, всё это посыпано некоторым слоем сахара, чтобы визуально уменьшить количество кода.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Вот маленький такой калькулятор, обращаю внимание на функцию eval. По моим субъективным ощущениям, эквивалентный джавовский код будет раза в 4 больше. Плюс появление (анти-)паттерна "визитор".
Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
Здравствуйте, LeonidV, Вы писали:
LV>Мне кажется, что Java очень простой язык. По крайне мере был до Generic'ов и Autoboxing. Чем что-то проще, тем удобнее и главное — безопаснее пользоваться.
Неверно. Берите тот же Форт — и вперед. Проще некуда — там даже синтаксиса-то как такового нет.
Улучшения в 1.5 реально позволили писать более надежные программы за счет улучшения работы статической типизации. Ну и сахар типа foreach/autoboxing/varargs тоже очень приятен.
LV>Более того, дайте простой инструмент, и мысли будут излагаться просто. Плюс, Java весьма академичный язык.
??
LV>Я посмотрел ссылку на ваш топик сравнения Java и C#. В принципе, он подверждает мою мысль. Яркий пример "мощного" языка — C++. Понапихали туда все ООП, которое только могли придумать.
ООП в С++ — это не главный источник сложностей. Даже близко не главный...
Спасибо за интересное мнение. Для меня пока выбор экзотического языка пока неоправданный риск, существует большая вероятность провалить проект по причине отсутствия личного опыта в этой самой "экзотике" и проблемой с поиском кадров (команда очень небольшая), поэтому я стараюсь очень осторожно подходить к выбору платформы, средств. Хотя будь у меня более менее крупная фирма я бы сформировал исследовательскую и "прорывную" группы, чтобы избежать деградации в «Падальщики» Та или иная технология должна достигнуть критической массы в отношении стабильности, качества и успешных применений, без этого использовать ее в production (особенно для заказных проектов, как в моем случае) крайне рискованно.
Здравствуйте, Дм.Григорьев, Вы писали:
LCR>>Вот маленький такой калькулятор, обращаю внимание на функцию eval. По моим субъективным ощущениям, эквивалентный джавовский код будет раза в 4 больше. Плюс появление (анти-)паттерна "визитор".
ДГ>Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
Здравствуйте, mkizub, Вы писали:
ДГ>>Кстати, а с каких пор "визитор" стал анти-паттерном? Ссылки на какой-нить старый флейм вполне хватит. =)
M>С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
Имеется в виду pattern matching? Если нет, то в чём отличие?
Здравствуйте, mkizub, Вы писали:
M>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
M>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
Все правильно говорит mkizub, только не совсем корректно. В чем человек думает не знаю, предполагаю что все-таки образами. А вот что он думает не линейно, это знаю. За подробностью к Тони Бьюзену.
Здравствуйте, LeonidV, Вы писали:
M>>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
LV>Все правильно говорит mkizub, только не совсем корректно. В чем человек думает не знаю, предполагаю что все-таки образами. А вот что он думает не линейно, это знаю. За подробностью к Тони Бьюзену.
Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом. Так что не правильно он говорит. Когда я продумываю архитектуру программы, в голове у меня с бешеной скоростью носятся всякие варианты использования с потоками управления. Даже в фоновом режиме сознание перебирает массу вариантов с огромной скоростью. Даже если этот "мультик" и имеет что-то общее с графическими образами (хотя на самом деле это больше похоже на некое "шестое чувство"), я бы с удовольствием посмотрел на конкретные инструменты сторонников "не только текстового синтаксиса". Чиста чтобы оценить, на сколько порядков они замедлят мне мыслительный процесс.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом.
Нет, дело не в этом.
Человек думает образами. Образ — это не обязательно картинка. Образ это образ. Символ, понятие. Когда компьютеру подсовывают картинку — он ещё должен понять, что там нарисовано, стол или глаз или буквы. Это называется распознаванием образов, так ведь? Вот этими образами человек и думает. Потом это передаётся в осознавание — в виде слов, кто умеет может в виде картинок и т.п.
Когда математик думает, он думает в образах интегралов, матриц и т.п. Когда врач думает, он тоже думает в образах связанных с болезнями, органами и т.п.
Чтоб компьютер мог автоматизировать умственную деятельность человека — он тоже должен уметь думать в образах. Что и делают компиляторы — они преобразуют текст программы в некое внутреннее представление, и в терминах этого внутреннего представления думает, то есть оптимизирует программу, переводит её на язык для CPU, чтоб тот исполнил программу.
Проблема нынешнего способа программирования в том, что этот набор образов (языка программирования) фиксирован. И фиксирован синтаксисом текста программы. Это звучит бредово, но так и есть — синтаксис, внешнее представление, ограничивает способ "думать" и набор понятий компьютера (компилятора). Фактически, человек точно так-же ограничен своим языком, и освоение новой профессиональной области начинается с изучения терминологии, а уже потом человек тренируется думать в этих новых терминах. Для компьютеров аналогично — поскольку мы тут про яву, то вспомни, сколько времени заняло введение новых фич в яву? Inner классы, да простейшие enum-ы... ГОДЫ. Почему так долго? Изменить один компилятор не тяжело, но кому нужны эти изменения? Нужно изменить все связанные средства программирования, от анализаторов кода и отладчиков до всех этих IDE (эклпису, идею, нетбинс и пр.). Потому как все они связаны между собой синтаксисом. У них разные внутренние представления явовской программы, а между собой они взаимодействуют по стандарту текстового синтаксиса.
Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления". Программирование прямо в семантических понятиях, единых для всех средств программирования. Если ты себе для проекта добавляешь новое понятие — с ним смогут работать все средства программирования... Например, мы вводим в наш набор понятий новую абстракцию "перечислымый тип". Мы её описываем неким способом понятным всем нашим средствам программирования — от редактора до отладчика, всем. Но! Редактор то понимает, что это enum, а вот как его редактировать и отображать — он не знает. И это надо будет редактору описать. Если нужно, а по умолчанию он может использовать некий "универсальный" способ представления (скажем, как в lisp — всё отображается в виде списка). Компилятор будет понимать, что вот тут стоит некий enum, но он не будет знать что с ним делать. Надо ему или рассказать как enum-ы выражаются через известный ему набор понятий (скажем, как в java enum-ы компилируются в классы), либо он должен поддерживаться непосредственно target platform, и надо будет поправить backend компилятора.
Графически-диаграммные средства разработки тоже имеют к этому некое отношение. В том смысле, что отображать программу вы можете как угодно. Она в компьюрете непосредственно в его внутреннем представлении хранится, а отображение/редактирование могут быть любыми. Хочешь — текстом. Хочешь — стрелочки рисуй. Хочешь — в UML диаграммах.
Здравствуйте, Дм.Григорьев, Вы писали:
M>>С тех пор, как появились языки с multimethods, то есть диспатчингом по рантайм типу нескольких аргументов.
ДГ>Имеется в виду pattern matching? Если нет, то в чём отличие?
Имеются в виду multimethods. Они легко находятся в google. В чём смысл я уже написал — диспатчинг метода по рантайм типу нескольких аргументов.
Для примера — virtual методы делают диспатчинг по рантайм типу только одного аргумента (this).
Здравствуйте, Trean, Вы писали:
T>Почему бы основной толпе не писать и дальше на Java, а профессионалам (ключевые или библиотеки, логика которых наиболее лаконично может быть выражена на другом, не Java языке) не перейти на Scala, если она действительно повысит их производительность?
Для библиотек как раз почти пофиг на каком они языке.
T>И кто потом будет разгребать все то, что наваял профессионал на очередном write-only языке, когда он уйдет? Я изредка заглядываю в ветку декларативного программирования и вижу, что там за код в примерах пишут, и где столько профи найти, чтобы написать целиком большой продукт?
Там вполне понятный код, просто синтаксис обычно немного странный. Например, тот же Erlang — исключетельно простой язык, проще даже чем Java. Просто там синтаксис не С-подобный.
Кроме того, многие возможности реально улучшают читабельность. Например, pattern matching часто заменяет громоздкие и сложночитаемые visitor'ы. Да даже простой foreach в Java 1.5 помогает читать код.
XJava,
XJ>>Java — платформа, которая решает большие бизнес задачи успешно уже многие годы. XJ>>Не мудро говорить, что из-за каких-то конструкций языка, которые кому-то не нравятся, Java загнется. XJ>>Сколько было языков и сред, которые загнулись, хотя были весьма красивы.
XJ>Кстати, для Java можно писать на Ruby и Python. Вперед использовать красоту!
Написал, отправил, удалил как ошибочное. Ну его нафиг, позориться только. А ты давай конкретные примеры, как ты собираешься формализовывать язык описания семантики. Сказки рассказывать все горазды.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, ralfeus, Вы писали:
R>>Прошу прощения за глупый вопрос. А почему у меня напечатало Figure? C>А это из-за того, что в Java нет мультиметодов
C>Просто я показал как они бы выглядели, если бы реально были.
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Мне лень искать, где и кто недавно флеймил на тему графических-диаграммных средств разработки, но от фразы "не ограничиваться текстовым синтаксисом" за версту разит этим бредом. Так что не правильно он говорит. <..> Я бы с удовольствием посмотрел на конкретные инструменты сторонников "не только текстового синтаксиса". Чиста чтобы оценить, на сколько порядков они замедлят мне мыслительный процесс.
Я уже писал. За подробностями к Тони Бьюзену. Инструмент называется Mind Map. Естестественно, что как и любой инструмент, он требует времени на изучение для эффективного использования. О кое-каких инструменах рассказывает Наполеон Хилл, но там немного из другой оперы.
Есть ещё kawa: хочешь — "схемь", но, ясное дело, с некоторым оверхедом. Можно "схемить" с типами — оверхеда намного меньше. Можно писать практически на Java в S-expr совсем без оверхеда, но с макрами и проч.
Ну и можно "скриптить" и REPL-ить — если очень надо или "для пробы"
Но это, конечно, для тех, кому это (списки-списки-списки...) подходит.
Здравствуйте, Alex EXO, Вы писали:
AE>На блоге расписал мысль несколько подробнее. AE>http://zay-note.blogspot.com/2008/01/blog-post.html
Спасибо! То, о чем смутно догадывался последние 2 года, но сам себе даже четко объяснить не мог, расписали по полкам. Особенно заинтересовала классификация в конце, раскатал по ней все компании, в которых работал: низкий старт был в "команде", которая через 3 года трансформировалась в "программистскую фабрику"; когда поднаторел и наскучило, пошел искать счастья в "орде"; не понравилось, решил, что поможет смены одной "орды" на другую — не помогло; разочаровался в "ордах", теперь ухожу в "программистскую фабрику", большие надежды, что это будет все же "команда".
Давно "не виделись"
M>Человек думает образами. Образ — это не обязательно картинка. Образ это образ. Символ, понятие. Когда компьютеру подсовывают картинку — он ещё должен понять, что там нарисовано, стол или глаз или буквы. Это называется распознаванием образов, так ведь? Вот этими образами человек и думает. Потом это передаётся в осознавание — в виде слов, кто умеет может в виде картинок и т.п.
"Положение": Абстрактная значимая детеминированная информация может обрабатываться человеком только в виде текста. Может конечно и в не текстовом виде, но только с предварительным текстовым описанием её или составляющих её частей.
M>Когда математик думает, он думает в образах интегралов, матриц и т.п. Когда врач думает, он тоже думает в образах связанных с болезнями, органами и т.п.
Эти "образы" вообще "существуют" только в сознании каждого конкретного человека. Обмениваться ими можно только "материализовав" их. В большинстве случаев для этого текст подходит наилучшим образом (за исключением технических чертежей, анатомических и прочих атласов и т.п., хотя это не противоречит "Положению"). Для описаний абстрактных действий (алгоритма в том числе) — альтернативы пока нет. Да, хочу оговориться: текст — это не только ASCII, это, грубо говоря, unicode с любыми расширениями, которые вы стандартизируете в пределах некоторого сообщества.
M>Чтоб компьютер мог автоматизировать умственную деятельность человека — он тоже должен уметь думать в образах. Что и делают компиляторы — они преобразуют текст программы в некое внутреннее представление, и в терминах этого внутреннего представления думает, то есть оптимизирует программу, переводит её на язык для CPU, чтоб тот исполнил программу.
И нафиг эта каша вместо "язык -> AST -> [маш]код"? Хотя и это справедливо не для всех реализаций.
M>Проблема нынешнего способа программирования в том, что этот набор образов (языка программирования) фиксирован.
Да ну? Любого-любого языка? И что фиксировано: синтаксис или семантика? И ни один язык не позволяет расширить их?
M>И фиксирован синтаксисом текста программы. Это звучит бредово, но так и есть — синтаксис, внешнее представление, ограничивает способ "думать" и набор понятий компьютера (компилятора).
С чего ты взял ,что это "бредово"? Ты не можешь строить дом из мед. препаратов, как и не можешь лечить людей промышленной продукцией группы А Так и с языком — ты не можешь "выйти" за его пределы, но у разных языков разные пределы. И не везде это _именно и только_ "синтаксис текста".
M>Фактически, человек точно так-же ограничен своим языком, и освоение новой профессиональной области начинается с изучения терминологии, а уже потом человек тренируется думать в этих новых терминах.
Так что в этом бредового? Или сначала изобретаем проблему чтобы затем с ней доблестно бороться?
M>Для компьютеров аналогично — поскольку мы тут про яву, то вспомни, сколько времени заняло введение новых фич в яву? Inner классы, да простейшие enum-ы... ГОДЫ. Почему так долго? Изменить один компилятор не тяжело, но кому нужны эти изменения? Нужно изменить все связанные средства программирования, от анализаторов кода и отладчиков до всех этих IDE (эклпису, идею, нетбинс и пр.). Потому как все они связаны между собой синтаксисом. У них разные внутренние представления явовской программы, а между собой они взаимодействуют по стандарту текстового синтаксиса.
И кто в этом виноват? Если бы javac был открыт и документирован вместе со своим AST-ом с самого начала и "торчал этими потрохам наружу", кто бы стал изобретать велосипеды? Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
M>Способ программирования о котором я говорю — это стандартизация семантики, некоего "внутреннего представления".
И нафиг новый "булшит", если есть AST?
M>Программирование прямо в семантических понятиях, единых для всех средств программирования. Если ты себе для проекта добавляешь новое понятие — с ним смогут работать все средства программирования... Например, мы вводим в наш набор понятий новую абстракцию "перечислымый тип". Мы её описываем неким способом понятным всем нашим средствам программирования — от редактора до отладчика, всем. Но! Редактор то понимает, что это enum, а вот как его редактировать и отображать — он не знает. И это надо будет редактору описать. Если нужно, а по умолчанию он может использовать некий "универсальный" способ представления (скажем, как в lisp — всё отображается в виде списка). Компилятор будет понимать, что вот тут стоит некий enum, но он не будет знать что с ним делать. Надо ему или рассказать как enum-ы выражаются через известный ему набор понятий (скажем, как в java enum-ы компилируются в классы), либо он должен поддерживаться непосредственно target platform, и надо будет поправить backend компилятора.
А может таки не строить в песочнице "три в одном"? Зачем редактору AST, если он изменяет текст программы? А отображение/создание новой конструкции может никоим образом не соотносится с её действиями.
Да и не надо "городить" "один AST во все языки". Либо у вас все языки получатся а-ля лисп (с типизацией и проч.), либо на некоторых языках простейшие действия будут отражаться страницами текста. И это ничего не будет говорить о том, что же на самом деле будет делать компьютер.
M>Графически-диаграммные средства разработки тоже имеют к этому некое отношение. В том смысле, что отображать программу вы можете как угодно. Она в компьюрете непосредственно в его внутреннем представлении хранится, а отображение/редактирование могут быть любыми. Хочешь — текстом. Хочешь — стрелочки рисуй. Хочешь — в UML диаграммах.
Бррр, в страшном сне не приснится....
Да, и я так и не смог понять, почему дерево нельзя создавать/изменять в текстовом виде (в виде списков или с отступами — как кому нравится).
Здравствуйте, Дм.Григорьев, Вы писали:
ДГ>Здравствуйте, mkizub, Вы писали:
M>>И не ограничиваться текстовым синтаксисом. Идти в сторону человека — иначе компьютер не сможет автоматизировать его умственную деятельность. А человек не думает в текстовом синтаксисе.
ДГ>Позвольте поинтересоваться, а в каком синтаксисе, по-вашему, думает человек? Вот Вы, когда программу продумываете, в каком виде она у Вас в голове крутится?
Лично у меня — в графическом (блок схемы, activity diagrams, классовые диаграммы, диаграммы последовательностей и тому подобное).
Наиболее удобная (по моему опыту) нотация для изображения процессов — язык ДРАКОН.
Здравствуйте, Аноним, Вы писали:
А>Bruce Eckel написал вчера в своем блоге, что все эти генерики и замыкания доведут жабу до цугундера. Ничего хорошего не получится и Java умрет. Жаль.
А>Шо делать? Си-шарпать?
Ага, или как вариант, Bigloo — более матёрый компилятор/интерпретатор, и коммьюнити поболее будет. Правда уже сам компилятор нативный, а не под jvm. Но как бы здесь уже нужно смотреть на задачу.
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
CU>>Есть ещё kawa...
LCR>Ага, или как вариант, Bigloo — более матёрый компилятор/интерпретатор, и коммьюнити поболее будет. Правда уже сам компилятор нативный, а не под jvm. Но как бы здесь уже нужно смотреть на задачу.
"JVM-нативность" как и скромный размер (даже вместе с JEmacs-ом) подкупают...
Здравствуйте, RI, Вы писали:
RI>Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это. RI>Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык.
Выше по теме заговорили про Scala: в курсе, что он компилируется в байт-код Java и в MSIL-код .NET? То есть при более выразительном синтаксисе получаем практически тот же байт-код. С учетом того, что платформы многоязыковые, ваш аргумент... сильно ни о чем.
RI>Думаю, что j2ee еще продержится не один год, слишком много уже на этой платформе сделано и продолжают делать. Люди готовы платить за яву.
Опять же синтаксис языка Java и платформа Java — как говорится, найди 10 отличий.
RI>Что совсем не уменьшает достоинства дотнета, просто не надо говорить что оттого, что мы будем писать на C# вместо Java все проблемы порешаются. Там свои косяки есть. И вообще сравнивать платформы надо.
Только в C# их исправляют, а в Java пока не заметно... это и расстраивает.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Исправляют. А потом появляются такие посты:
[skipped]
Читал все эти темы. Все это говорит о том, что C# становится все более и более сложным инструментом, который, с одной стороны, опасен для ньюби, но с другой стороны, предоставляет профессионалам инструмент с более тонкой настройкой, который позволяет делать все намного проще, лаконичнее, интуитивно понятнее. То есть о чем собственно писал по ссылке, которую давал в своем сообщении выше (про сравнение C# и Java): профи хотят инструмент похитрее-поудобнее — если этого не даст язык Java, неминуем отток в сторону той же Scala — разумеется, незначительный, только на основе энтузиазма: постоянного желания повысить производительность своего труда, адекватный интерес к новым веяниям в ИТ.
ANS>По, например, вопросам добавления лямбд у Блоха адекватная позиция — типа решите, вы хотите пофиксить "синтаксический оверхед" или новых фич напихать.
Хм...
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
CU>>Или месье совершенно не знаком с gcc, который расшифровывается совсем не как GNU C compiler?
LCR>Да, а как? Generalized common compiler?
Здравствуйте, mkizub, Вы писали:
CU>>>И нафиг новый "булшит", если есть AST?
M>А AST стандартизирован?
Я не про стандарт AST-а говорю, я про "мыло для идиотов": `некоего "внутреннего представления"`. Пишите на более менее строгом техническом языке, а не для детсада...
M>Самый Базовый Язык может быть разным. Трансляция из одного языка в другой. Другой может быть C, может MSIL, может ява байткод, или некий абстрактный Самый Базовый Язык. Которых, самых базовых, может быть сколько угодно. И занимается трансляцией backend. А компилятор имеет у себя набор узлов, и может заниматься tree transformation как ему захочется.
А почему эту tree transformation никак нельзя однозначно выразить в тексте и это и сделать "самым базовым языком".
В принципе я не про "базовость", я про необходимость знания что скрывается в том или ином языке за той или иной инструкцией/набором инструкций (в тех случаях, когда определённая "трансформация" не может быть "переведена" в одну инструкцию в выбранном языке). Т.е. я _всё равно_ хочу а-ля ASM (текстовый) для всех этих деревьев.
M>Он "думает" в этих терминах. А с человеком обменивается информацией через текст, через UML диаграмы, через визуальное представление диалогов и т.п. Ты, наверное, путаешь концепцию представления программы в виде дерева с концепцией компилятора с множеством backend-ов. У такого компилятора есть некое "стандартное" внутреннее представление, в которое преобразуют frontend-ы, и из которого генерируют программы backend-ы. А разница в том, что у GCC и подобных — внутренне представление фиксированное, а при подходе о котором я говорю — это расширяемый набор узлов/понятий.
Менять поведения компилятора по мере компиляции? Отлично! Давно хочу. Только хоть прибейте меня — не пойму почему это нельзя выражать текстом.
M>Например, мы вводим понятие closure. Оно самостоятельное понятие. Но оно может быть преобразовано в другие. Для Java некий плагин/backend к компилятору его преобразует в inner class,...
Вот за это "расстрел на месте". Т.е. смотреть в текст Java и догадываться, что вот эти 10 строк кода являются "одним узлом"? Нафиг здесь тогда Java? "Универсальные" программы будут получаться "экстремально" не эффективными. Ибо кодируя на Java ты знаешь цену тех или иных подходов, а в вашем случае?
Здравствуйте, rsn81, Вы писали:
RI>>Кого интересует ЯЗЫК ? Главное — это платформа, сейчас ориентация идет в первую очередь на это. RI>>Синтаксис языка — подробности. Хотя язык и "формирует мышление", но Java даже без наворотов версий 1.5-1.6 достаточно мощный ОО язык. R>Выше по теме заговорили про Scala: в курсе, что он компилируется в байт-код Java и в MSIL-код .NET? То есть при более выразительном синтаксисе получаем практически тот же байт-код.
Есть некоторые подозрения, что "джависты" будут писать на Scala код "оптимальный" для JVM, а "дотнетчики" — для .NET
Здравствуйте, cl-user, Вы писали:
CU>Есть некоторые подозрения, что "джависты" будут писать на Scala код "оптимальный" для JVM, а "дотнетчики" — для .NET
Оптимальный Java байт-код на Scala — вряд ли, посмотрите байт-код который генерирует Scala-компилятор... А у .NET-программистов есть уже, в принципе, своя религия — Nemerle.
Здравствуйте, <Аноним>, Вы писали:
А>Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Вы о MS JVM? Насмешили...
А>Но ниче жива еще . И даст бог протянет ще не один десяток .
Десяток — вряд ли.
Здравствуйте, LeonidV, Вы писали:
LV>Чем более сложный язык, тем проще одному опытному программисту написать так, что другой опытный программист его не поймет. В результате получаем developer-locking
Разумеется, только выше уже приводили достаточно серьезный аргумент против этой точки зрения... точнее взгляда на данный вопрос только под этим углом.
LV>А "интуитивно-понятней" в данном контексте для меня "хрен-знает-как-но-работает". Я сторонник простых языков. И вещей в целом. И привязанность к как можно более простым вещам у меня идет после книг Раскина, Купера и других. В часности, Купера пишет о любви программистов к сложным вещам. И откуда эта любовь берется. И почему это плохо, тоже пишет.
Даст бог, дойдут руки и до этих авторов, пока на года вперед книги расписаны.
Простые вещи хороши "в данном контексте" до поры до времени, пока они хорошо справляются с поставленными задачами. Когда же назревает явный и ощущаемый (хотя бы некоторым значительным количеством) сведующими в теме недостаток, бывает проще отказаться от простого инструмента, который попросту не может объять слишком сложную сущность, в сторону некоторого относительно более сложного инструмента, который справится с этой задачей с меньшими трудозатратами, то есть трудозатраты на изучение и использование нового инструмента будут меньше, чем без него. Как пример, когда-то концептуальную сущность программ можно было описать блок-схемой алгоритма, теперь уже чаще UML, да и то... спорный инструмент. Не говорю, что Java сильно не справляется с текущими задачи, вовсе нет, но ощущается, что это может стать реальностью через несколько лет такого упорного консерватизма.
Здравствуйте, Аноним, Вы писали:
А>Это точно что Джаву хоронят уже много лет. ГГ еще в 2001 году когда Микрософт отказался от поддержки Джавы ходили такие разговоры.
Во-во. Помню как кричали что Яве конец, когда C#.NET появился.
Здравствуйте, Kisloid, Вы писали:
ANS>>Ходить туда лень. Но что-то мне помниться, что связано со словом "collection"
K>Угу, GNU Compiler Collection, но раньше оно расшифровывалось как GNU C Compiler.
[joke]
Это при царе-горохе^W^W когда его RMS писал что-ли?
[/joke]
Не обязательно использовать весь тот мусор, который понавесят в новых версиях. А то будет нечитабельное гуано как в скале, в которой синтаксический ###### достиг чуть ли высшего предела, судя по приведенным выше примерам. 
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
.
