JVM не будет поддерживать Python

import java.util.*;


interface Predicate<T>
{
	boolean isTrue(T value);
}


class Algorithms
{
	public static <T> void remove_if(Iterable<T> c, Predicate <T> pred)
	{
		for (Iterator<T> i = c.iterator(); i.hasNext();)
		{
			T value = i.next();
			if (pred.isTrue(value))
			{
				i.remove();
			}
		}
	}
}


class Test
{
	public static void main(String[] args)
	{
		List<String> words = new ArrayList<String>(
			Arrays.asList(new String[] {
				"age", "lap", "ape", "star", "sun", "ant" }));
		final int[] count = {0};

		System.out.println(words);

		Algorithms.remove_if(words, new Predicate<String>() {
				public boolean isTrue(String s) {
					if (s.startsWith("a")) {
						count[0]++;
						return true;
					} else {
						return false;
					}
				}
			});

		System.out.printf("%d words removed\n", count[0]);
		System.out.println(words);
	}
}

А вот за отсутствие нормального оптимизированного tail recursion стоило бы попинать как раз Гвидо, который мало того что не сделал ее до сих пор, так еще и не хочет делать ее вообще по принципиальным соображениям: рекурсивный код, видите ли, малочитабелен...

Малочитаем может быть синтаксис, код в отрыве от синтаксиса скорее малопонятен.

Я прекрасно понимаю почему GvR не желает добавлять в язык подобные вещи. Причин несколько: 1. Питон за последние года три претерпел достаточно масштабные изменения и в планах еще очень много. Есть мысль, что в Python 3000 надо скорее отбросить часть функциональности... У меня сложилось мнение, что они хотят в нем добавить интерфейсы и выкинуть большинство атавизмов и non-pythonic решений. Хотя, надеюсь, list comprehansions они оставят. 2. Динамическая природа языка и полный (позволяющий даже больше, чем просто python) C API позволяет сделать очень многое в библиотеках.

времена Java проходят, начинается время массового применения Python
ещё один пример того как OpenSource вытесняет проприетарь.
Linux вытесняет Win, Firefox вытесняет IE+Opera, C# с треском провалился,
теперь и очередь за жабой

вывод: если затеивать что то массовое то делать только OpenSource

> Java совершенна. Она - эталон языкостроительства, вобравшая в себя все лучшее и отвергнувшая все худшее. Нет, возможно лет через 150 и появится какой-нибудь новый язык, но пока ничего лучше java нет.

Это стёб?

>Опытные java-программеры всегда с большим уважениеми отзываются об этом языке.

не о языке. О среде.

to Sda

именно о языке они отзываются. о какой "среде" вы толкуете? между прочим именно язык, его простота, ясность и отсутвствие двусмысленностей позволил создать такие средства разработки как Eclipse и IDEA. Замечу, что обе этих IDE написаны на Java и обе дают Джаве то, чего нет ни в одном другом языке (за исключением С#) - рефакторинги кода. Для С++ не видел (и никогда не увижу, потому что никто этого не сделает) рефакторинг тула.

--седайко стюмчик

> Это стёб?

Угадайте с трёх раз.

>Для С++ не видел (и никогда не увижу, потому что никто этого не сделает) рефакторинг тула.

Увидите, если не будете закрывать глаза. Навскидку: http://www.xref-tech.com/xrefactory/main.html. То, что для java много ФУНКЦИОНАЛЬНО неплохих IDE это конечно факт и это радует. Однако это НЕ ГОВОРИТ о крутизне языка или "среды" как некоторые изволят выражаться. Это говорит о раскрученности и только. Если говорить о непротиворечивости, надежности, стройности - то из ныне существующих яп общего назначения, первое место несомненно у Ada. Ну а простота подчас хуже сами знаете чего. Простота java провоцирует плохое качество кода и в следствие - огромное потребление ресурсов java приложениями. Согласитесь - забавно когда IDE - например IDEA требует для нормальной работы 1G - и это для одного человека! Мне кажется это уродство. Ведь например Oracle на 8G обрабатывает 100-140 конкурентных DSS сессий. Хотя может быть я слишком требователен ... Несомненно называющих себя программистами на java куда больше чем таковых на С++, однако НАСТОЯЩИХ программистов и там и тут примерно одинаково и что интересно - хороший спец по java почти всегда является хорошим спецом по С++. Я говорю это полагаясь на свой опыт интервьюирования и в россии и в штатах.

>именно о языке они отзываются.

тогда это свосем не "опытные". Как язык Java сосёт, даже у javascript. Причём с запасом. Про event handling тут уже говорили.

>о какой "среде" вы толкуете?

J2SE, J2EE, J2ME

>позволил создать такие средства разработки как Eclipse и IDEA

ну и чё? Emacs?

> чего нет ни в одном другом языке (за исключением С#) - рефакторинги кода

:)

"UNIX haters handbook". Читать.

> именно о языке они отзываются. о какой "среде" вы толкуете? между прочим именно язык, его простота, ясность и отсутвствие двусмысленностей

Необходимость постоянного боксинга/анбоксинга в жабке до 1.5 при работе с коллекциями - это, по-вашему, в какую категорию попадает: простоту, ясность, или отсутствие двусмысленности? А пинать плюсы жабщикам вообще последнее дело - сделайте сначала что-то, приближающееся по мощности хотя бы к STL, не говоря уже о boost, тогда будет о чем-то разговор.

to dsa: вы ламер (извините, но этот так). J2SE, J2EE, J2ME это не среды программирования, это всего ли версии библиотек + их спецификации для Джава машины. Про феракторинги вы, похоже, вообще не знаете. Поиск в IDEA или в Eclipse использования метода это не текстовый поиск в коде его имени. Нужные книжки я все цже прочёл в детстве, однако, спасибо за совет.

to int19h: боксинг нужен только лишть для примитивов. при этом вас никто не обязывает пользоваться именно java.util коллекциями. возьмите к примеру trove и работайте напрямую с примитивными типами. пожалуйста, не валите всё в одну кучу. К вопросу об STL. IMHO - это полное Г, т.к. построение программ на шаблонах - это Г. Естесственно, вы со мной не согласитесь :)

а вообще спорить о языках бессмысленно. каждый выбирает совё и получает от этого тоже своё :) на этой дружеской ноте предоагаю этот lauguage флэйм закончить.

--седайко стюмчик

Хе-хе... Будете смеяться, но для змейки рефакторер есть. Сами найдете , или носом тыкать? Называется, правда, странно, но на удивление - таки работает :-)

> боксинг нужен только лишть для примитивов

Да, а вот приведение типов - для всего вообще. О каком "type safety" может вообще идти речь при таком раскладе?

> при этом вас никто не обязывает пользоваться именно java.util коллекциями. возьмите к примеру trove и работайте напрямую с примитивными типами.

Угу, а свои специфичные коллекшены мне тоже писать в десяти версиях - для Object и по одной для каждого primitive type?

> К вопросу об STL. IMHO - это полное Г, т.к. построение программ на шаблонах - это Г. Естесственно, вы со мной не согласитесь :)

Естественно, не соглашусь. Вы считаете, что generic programming - это отстой? вам больше нравится писать одно и то же по десять раз, или же вы предпочитаете предварительно прогонять свой код через препроцессор для автоматической генерации всех возможных версий?

К счастью, Sun с вами не согласился. И добавил generics в 1.5. Пусть и местами убогие по сравнению с плюсовыми шаблонами, но даже и они позволили жить намного легче.

не generics programming отстой, а шаблоны C++ и слава богу Сан со мной согласен в этом :)

я понял что вы считаете "неубогим": то что позволяет выпендриться, написать строчку "олимпиадного" кода, а потом ваши братья-программисты будут сидеть и разгадывать логику спрятанных неявных преобразований :) вот это и есть зло! Джавовские дженериску прозрачные и это _не_шаблоны_

--седайко стюмчик

>сидеть и разгадывать логику спрятанных неявных преобразований

Бесспорно - неявные преобразования это проблема С++. Хотя это скорее 
проблема С, а в С++ - если это целесообразно - можно элементарно 
реализовать например все базовые типы ввиде классов ЗАПРЕЩАЮЩИХ 
неявные преобразования. Т.к. Вы эксперт в С++, я думаю Вы поймете 
идею. Однако я немогу понять каким боком это относится к шаблонам?

>Джавовские дженериску прозрачные 

Увы это к сожалению не так! Реализация, как вообщем и идея довольно 
крива. Взгляните например на сановскую реализацию контейнеров. Или 
например почему я немогу написать:

public class Dummy<T> {
  public T blah() {
     return new T() // низзя!
  }
  public T blah1(T p) {
     T my_p = p.clone() // низзя!
  }
}

даже

public class Dummy<T extends Clonable> {
  public T blah1(T p) {
     T my_p = p.clone() // низзя!
  }
}

И куча еще всякой муйни, которая упирается в то, что java runtime незнает НИЧЕГО о generic-ах.

В то время как мощь C++-темплейтов (даже страдающих недоработками) просто потрясающа. Взгляните например на loki, boost, или почитайте о expression templates.


>и это _не_шаблоны_

"Армянин лучше чем грузин".
"Ну чем, ЧЕМ ЛУЧШЕ!!!???"
"Чем грузин..."

P.S.

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

За сим позвольте откланяться.
Удачи всем.

Гандон, ты говорил бы о том, что знаешь.

> не generics programming отстой, а шаблоны C++ и слава богу Сан со мной согласен в этом :)

Объясните поконкретней, чем вам не нравятся шаблоны в плюсах. У меня к ним есть одна большая претензия: отсутствие возможности задать дополнительные ограничения на параметризованный тип. Т.е. я хочу не просто typename T, а некий T, для которого определен оператор < и функция abs.

> я понял что вы считаете "неубогим": то что позволяет выпендриться, написать строчку "олимпиадного" кода

Это типа например:

list<int> l; ... remove_if(l.begin(), l.end(), bind_2nd(less<int>(), 10));

вместо:

List l ... for (Iterator i = l.iterator(); i.hasNext(); ) { if (((Integer) i.next()).intValue() < 10) { i.remove(); } }

Это первая строчка кода на плюсах - "олимпиадная"? Ну да, при таком подходе со стороны Java-девелоперов понятно, почему enums, varargs, и прочая вкусность появились в жабке только после того, как они засветились в C#. А что, я еще помню, как на здешних форумах меня кто-то убеждал, что, дескать, enum'ы - совершенно лишняя роскошь, и обычные int'овские константы - это куда более "объектно-ориентированно", а главное - просто и понятно. Вот такие пироги.

Ладно, умолкаю... эту тему я лучше отдам на откуп Луговскому - у него это более экспрессивно получается =)

Любая среда не более чем костыль к языку. ;) Рефакторинг - это тоже не более чем костыль, хотя другого рода. =)

Гы... В Лиспе то всё ещё хуже. Лучше половинчатая "строгая" типизация, чем вообще никакой.

Проблема Java в том, что это не язык, а платформа. И, как платформа, заточенная под *один* язык, она есть зло. Как язык Java неплоха, и имеет право на существование, но вот в платформе есть очень много того, что следовало бы поменять.

Да понятно, что сделать можно. Всё сделать можно. Неэффективно-с получается-с...

А ты можешь объяснить внятно, на фига нужен язык, в котором нужен рефакторинг?

Питон не змейка, а Монти...

А что тут непонятного? Рефакторинг - это тоже работа, она тоже стоит денег.

Я не понимаю смысла в такой работе. Разве что только очковтирательством заниматься...

>А ты можешь объяснить внятно, на фига нужен язык, в котором нужен рефакторинг?
наивно предположение о том, что основной причиной рефакторинга является ЯП

Ну как раз-таки с точки зреня Java это не совсем так. Рефакторинг - это приведение кода, испорченного многочисленными добавлениями и исправлениями, в приличный вид. Зачастую это дешевле чем отсраивать систему с нуля или переписывать отдельные куски. Тем более что костыли (читай, IDE) это позволяют делать это быстро и более-менее правильно. Но это тоже работа, она требует много внимания от разработчика, следовательно времени на ее завершение. Это время должно оплачиваться (более того, это время как правило закладывают в процесс разработки, а его стоимость соответсвенно в бюджет проекта). Понятно что это может занимать много времени, много ресурсов и, соответсвенно, стоить много денег. На мой взгляд это не избежно при разработке большой сложной системы. Можно ли обойтись без рефакторинга при разработке большой сложной системы? Какмими средствами и на какой платформе (читай языке) Вот это как раз интересный вопрос...

> А ты можешь объяснить внятно, на фига нужен язык, в котором нужен рефакторинг?
требования имеют свойство менятся, причем иногда на 180 градусов,
а возможность эффективного рефакторинга - большой бонус для языка.

Причиной является используемая методология проектирования. Язык всегда является следствием выбранной методологии. Жаба - это язык, вышедший из ООД. ООД провоцирует рефакторинг. ООД и ООП - суксь, потому как спровоцированний ими рефакторинг - суксь. Жаба, следовательно, тоже суксь.

Тогда и Python - суксь

питон несовершенен но с каждым релизом становится всё более совершенным на фоне уродливой, умирающей лягушки

Возникновение такого кода в процессе разработки говорит только об одном - о крайне низкой степени возможного code reuse. В языках, допускающих существенно более высокие степени абстракции, такого не бывает - уже написанный код мы не исправляем, а дополняем. Поменялись требования - дополним по другому, ничего не трогая в уже написанном.

Какая платформа? Лисп, Haskell... Желательно, без всяких там попсовых глупостей, вроде объектно-ориентированного дизайна системы.

Суксь. Но в нём как минимум есть лямбда и зачаточные возможности метапрограммирования, что позволяет строить более абстрактный код, и, соответственно, значительно снижает потребность в рефакторинге.

Ах вот вы об чем! =) ФП - это совсем другой уровень, кто знает может за ним будущее. ;)

> В текущей фирме, где я сейчас работаю мы ищем около 6 Java-программистов и готовы платить от 1000 долларов и это высокая зарплата для нашего города, вот только нормальных java-программеров найти не можем (((

Что за город, если не секрет?

Лямбда и прочие ФП-конструкци к P3K изчезнут. Метапорграммирование... хм... Разве метапрограммирование в питоне не подчиняется тем же принципам, что заложены в ООП? А если так, то его неизбежно ждет рефакторинг... Метарефакторинг? Метасукс. ;))

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

да и без лямбды неплох

Плох, оченно даже. Всего лишь очередное динамическое приООПнутое поделие получается, если без лямбды. List comprehensions не спасают - синтаксический сахар вообще языки не украшает, гораздо лучше возможность произвольного расширения синтаксиса.

> Суксь. Но в нём как минимум есть лямбда

Какая там нафиг лямбда? Там даже conditional operator нет...

Кстати, а вот в столь нелюбимых тобой плюсах лямбда как раз есть - в boost =)

> Плох, оченно даже. Всего лишь очередное динамическое приООПнутое поделие получается, если без лямбды. List comprehensions не спасают - синтаксический сахар вообще языки не украшает, гораздо лучше возможность произвольного расширения синтаксиса.

Тогда тебе дорога к Ruby. Тот же питон, но с _самого начала_ сделанный по уму. Жаль, либ мало...

>><b> У Javы полно непредсказуемостей и нелогичностей поведения. Кому >>нужна хэш-таблица, в которую мона сунуть любого наследника Object-а, >>и вынув, попытаться кастануть к любому другому?!?
>>
>>У сешарпы та же проблема, к слову. Просто вы ламер, вот и всё... >></b>

>Ха - а ты что - хочешь для каждого типа объектов свой HashMap >создавать ?
На C++ - легко и непринужденно. template <class T> ....

>Кстати, а кто тебе мешает свой аналог HashMap создать, который будет >работать с одним типом объектов ??? И еще - что ты за программист, >если ты не знаешь, какого типа объекты попадут в таблицу ??? )))) И >что тебе мешает делать проверку на типы - скажем используя инструкцию >instance of ??? )
А зачем?

>И сразу возникает вопрос - если бы ты был архитектором языка, то ты >бы для каждого типа объектов свой бы HashMap придумал ??? Да тебя бы >уволили сразу как бездарного архитектора.

Страуструпа за template никто не уволил. И бездарью лишь немногие называют.
Кстати, нечто схожее легко и красиво на python делается, что даже как-то на мысль навело (мимолетную), что сам python с шаблонами работает. Типа сделал алгоритм, и главное, чтобы используемый в алгоритме класс нужные методы поддерживал.

Да и на JAVA 1.5 вроде template появились, если я только с C# не путаю.

Разве Ruby не от perl'a пошел?

>Согласитесь - забавно когда IDE - например IDEA требует для нормальной работы 1G - и это для одного человека! Мне кажется это уродство.

И что? 1Гиг памяти знаешь сколько стоит? ~ $200. Месяц твоей работы сколько стоит? Месяц работы кооллектива из 3-х программистов кодеров сколько стоит?

"Машина должна РАБОТАТЬ, а человек должен ДУМАТЬ"© IBM

>Ведь например Oracle на 8G обрабатывает 100-140 конкурентных DSS сессий.

Что, Оракел это полноценный ООП ЯП? Что, он тучу объектов создает на каждую сессию? "В Java всё - объекты" (в идеале) поэтому и IDE соответственно - объектная , а значит и памяти жрет на свой GUI недетски, но это не означает, что написанная в этой IDE прога тоже будет жрать такой же объем памяти.

Ткните в простое объяснение, что есть боксинг/анбоксинг? (В гуугл не посылать, умел бы - уже сам бы нашел) Ткните в простое объяснение, что есть женерикс? Ткните в простое объяснение, что есть write barrier?

Спасибо

Клоуны, которые пинают Яву: посмотрите на строку в адресе страницы, которую видите в данный момент, хотя бы. :) LOL

>Ткните...
http://java.sun.com/developer/technicalArticles/releases/j2se15/

О! Вот и наконец вменяемый конкретный критик Antik появился.

> Жаба, следовательно, тоже суксь.

Что, тады, не суксь? Python уже отбросили. Остались Haskell & Lisp?

Какие промышленные программы написаны на Haskell? На Lisp? Промышленные - размера так с Photoshop, Oracle, Windows 2003 server?

>to dsa: вы ламер (извините, но этот так). J2SE, J2EE, J2ME это не среды программирования, это всего ли версии библиотек

мда? Ну что ж, тогда и Symbilcs занималась всего лишь навсего выпуском библиотек... Да и, что такое Linux, как не собрание бибиотечных сисколов?

>Про феракторинги вы, похоже, вообще не знаете

если это тебя сделает счастливее, можешь так думать

>а вообще спорить о языках бессмысленно. каждый выбирает совё и получает от этого тоже своё :)

спорить не стоит. Языков есть только три - Lisp, Fortran и C. Всё остальное - жалкие их подобия и убогие реинкарнации.