Список перспективных технологий

[АццкоМото]

Ну ты же сам понимаешь, что не в языке дело, а в плагине. А то, что плагин может быть сыроват под Juno при каких-то конфигурациях, то все может быть. У меня, кстати, Scala Ide for Eclipse плагин без проблем под Juno бегает.

Конечно, понимаю. Но ты же сам понимаешь, что самый распрекрасный язык, у которого самая мейнстримовая тулза глючна НАСТОЛЬКО вообще никому нафиг не нужен. Ну, в идеале

[Интеррапт]

А меня раздражает принципиально избыточная фича, поддерживаемая на уровне специального синтаксиса. Есть переменные, а есть - функции. Если заканчивается на () - значит функция, нет - переменная. А тут какой-то огород - ну чем геттеры-сеттеры такие особенные по сравнению с другими фукциями?!

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

Ну сам писать не буду, лучше скопирую из "интернетов"

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

- Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
- Hiding the internal representation of the property while exposing a property using an alternative representation.
- Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without effecting existing consumers.
- Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
- Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
- Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
- Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
- Allowing the getter/setter to be passed around as lambda expressions rather than values.
- Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.

[Medium-rare]

Да я не спорю (я пока и не разбирался методично с C++11, надо бы как-нить почитать...). Просто подумалось: вот выпустили вначале C++, а STL/standard library - забыли.

Страустрап не монстр же, а тоже смертный. Затем Степанов тоже почему-то добавил полезности не хило с STL, а ишь ты, не всё даже в пределах не самой большой библиотеки предусмотрел. Затем целая толпа с Boost и докладыванием в STL, тоже как-то недоработали до идеала.

В результате все понаписали туевы хучи сомнительного качества кода для работы с самопальными коллекциями, строками и т.д. Потом спохватились, добавили коллекции и строки, но какая-то часть девелоперов и проектов ушла от C++ куда-то в другую сторону. А оставшиеся получили долговременный "фан" в виде необходимости сочетать новые коллекции и строки с оставшимся в наследство говнокодом.

Да-да, столько радости, сколько сопровождение многолетнего сишного плоского кода, ничто не приносит.

Теперь вот ещё что-то добавили; threading support in the language? Добро пожаловать поженить это с кодом, в котором threading сделан на уровне platform API (threading я взял для примера, может чего-то и не то говорю - просто идею иллюстрирую).

Более того, активно объясняют, что использование threads напрямую - только по чётко осознанной необходимости, а для распараллеливания есть std::async. И большое им спасибо за доведение этой мысли до широких масс трудящихся.

То есть я охотно верю, что выйди C++11 тогда, как новый язык - было бы замечательно.
А сейчас, боюсь, не так уж много программистов и проектов останется, кто бы стал его использовать как general-purpose language.

Я сам ещё совсем недавно был большим поклонником C++, только вот смотрю, что он всё больше используется в каких-то причудливых нишах, которые ну никак не фан. А всё основное пишется на Java (ну или .NET в отдельных географиях, говорят).

Что забавно, MS, вроде как, положивши столько сил не так давно на изведение под корень нативного прикладного программирования (.Net, как-то всё тише теперь про него), даёт теперь ему зелёный свет. Идея об общей код-базе для десктоп - таблет - телефонных аппов превалирует теперь. А потребности в CPU и памяти, прямо сейчас, очевидно, растут в слишком сильной привязке с выделяемым теплом. Серверы сильно греются. Таблеты (слейты их некоторые называют) греются. Телефоны жрут батарейку, как не в себя на новых аппах.

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

[Интеррапт]

Ну ты же сам понимаешь, что не в языке дело, а в плагине. А то, что плагин может быть сыроват под Juno при каких-то конфигурациях, то все может быть. У меня, кстати, Scala Ide for Eclipse плагин без проблем под Juno бегает.

Конечно, понимаю. Но ты же сам понимаешь, что самый распрекрасный язык, у которого самая мейнстримовая тулза глючна НАСТОЛЬКО вообще никому нафиг не нужен. Ну, в идеале

У меня не глючит, у Крипто5 не глючит, у тебя глюкнула - (а) ну бывает, у меня Эклипс и на GWT глюкался (б) не факт, что это Скала плагин виноват.

[crypto5]

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

"Пилюшин сморгнул, но женщина осталась". Да вроде как вынес все, а нифига, результат тот же. Новая копия Juno старый воркспейс не всасывает с той же проблемой. Т.е. встретился глючный плагин с глючным IDE. Стектрейс был мутный (грохнул уже), на скалу ничего явно не указывало, NPE где-то в Эклипсе, но совпадений таких один хрен не бывает

Ну значит не судьба, такое тоже бывает.

[M. Ridcully]

А если в каком-то сабклассе вы решите, что вам нужно переписать поведение этой функциональности.

Интеррапт, я скорее всего эти книжки тоже читал .

А почему бы не изобрасти специальный синтексис для другим идиом и паттернов? Давайте придумает какую-нить специальную, особую семантику для функций createXXX - типа factory-method? Или какой-нить хитрый shortcut для функций onXXX, чтобы observer имплементировать? Или.... а может, остановиться и не городить этот огород?

Я если честно вообще такой стиль, где много геттеров-сеттеров (безотносительно - сгеренённых или рукописных) не люблю. Мне кажется, что что-то не то с дизайном, где их много (если не говорить о какой-то очень узкой специфической области, типа UI).

[Интеррапт]

Интеррапт, я скорее всего эти книжки тоже читал .

Отлично. Тогда нам будет легче понять друг-друга

А почему бы не изобрасти специальный синтексис для другим идиом и паттернов? Давайте придумает какую-нить специальную, особую семантику для функций createXXX - типа factory-method? Или какой-нить хитрый shortcut для функций onXXX, чтобы observer имплементировать? Или.... а может, остановиться и не городить этот огород?

И вы не так уж и неправы. Например, в C# есть специальный синтаксис для делегатов. Отличная вещь. И properties есть. То, чего в Джаве нет. И как-то никто не жалуется, что это избыточная вещь, а наоборот, используют в полный рост.
Для createXXX скорее всего синтаксис не нужен, потому что их у вас редко когда будет больше чем несколько штук в классе. А вот getters/setters может быть очень много в models.

Я если честно вообще такой стиль, где много геттеров-сеттеров (безотносительно - сгеренённых или рукописных) не люблю. Мне кажется, что что-то не то с дизайном, где их много (если не говорить о какой-то очень узкой специфической области, типа UI).

А при чем здесь дизайн, если у вас есть модель с именем/фамилией, почтовым адресом, гордом, штатом, телефоном, и еще десятком полей? Можно конечно это по разным классам разнести (типа почтовый адрес в отдельный класс), только от этого кол-во setters/getters и строчек с тупыми javadocs - не изменится.

[M. Ridcully]

А при чем здесь дизайн, если у вас есть модель с именем/фамилией, почтовым адресом, гордом, штатом, телефоном, и еще десятком полей?

Описанное выше - это просто данные. Пока не ясно, зачем вообще нужен класс.

Другими словами - у класса должны быть какие-то responsibility, он должен что-то делать. Тупая инкапсуляция данных как responsibility не канает, это anti-pattern.

[M. Ridcully]

И вы не так уж и неправы. Например, в C# есть ...

Ну ОК, спишем это на субъективность. Вам - нравится, мне - нет.

Мне вообще последнее время с эстетической точки зрения нравится программировать на C и на Питоне (без классов).

[Интеррапт]

Описанное выше - это просто данные. Пока не ясно, зачем вообще нужен класс.

Извините, но в Java нет структур (в их Сишном понимании). Есть только классы.

Другими словами - у класса должны быть какие-то responsibility, он должен что-то делать.

Ну попробуйте описать JPA Entity без класса.

Тупая инкапсуляция данных как responsibility не канает, это anti-pattern.

Ссылочку можно на то, что класс с данными, но без логики - это anti-pattern?

[АццкоМото]

Ну сам писать не буду, лучше скопирую из "интернетов"

There are actually many good reasons to consider using accessors rather than directly exposing fields of a class - beyond just the argument of encapsulation and making future changes easier.

Here are the some of the reasons I am aware of:

- Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
- Hiding the internal representation of the property while exposing a property using an alternative representation.
- Insulating your public interface from change - allowing the public interface to remain constant while the implementation changes without effecting existing consumers.
- Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
- Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
- Improved interoperability with libraries that are designed to operate against property getter/setters - Mocking, Serialization, and WPF come to mind.
- Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
- Allowing the getter/setter to be passed around as lambda expressions rather than values.
- Getters and setters can allow different access levels - for example the get may be public, but the set could be protected.

Ну, в энторнэты-то КО писал. Я немного не о том толкую. Нет никакого смысла генерить "про запас" методы доступа, в которых нет никакой логики.
Вот если бы было такое чудо, я бы двумя руками его пожал (условный псевдойызык, сам с него ржу)

Code: Select all

class A {
   virtual public int i;
}
class B: A {
   @override
   A::i {
   public int get () {
      return A::i*28;
   }
   public void set (int _i) {
   if (i>5) throw new exception ("I'm class B, not A, and care only about values not greater than 5");
      i=_i;
   }
}
void main () {
   // This returns an instance of B
   A a = someClassFactory ("Gimme an instance of B");
   a.i = 7; // And this throws an exception...
}

Вот это бы почесало и принципы ОО и банальную лень. А пока выглядит все тухло

[АццкоМото]

У меня не глючит, у Крипто5 не глючит, у тебя глюкнула - (а) ну бывает, у меня Эклипс и на GWT глюкался (б) не факт, что это Скала плагин виноват.

Да понятно, что не свезло и не факт, что вина именно Скалы. Но осадок-то остался. Как-то все immature, не смотря на 9-летний возраст.
А краткий экскурс по самому языку мне скорее понравился, чем нет. Не могу еще сообразить, понравится ли на нем писать, но отторжения не вызывает, а что-то хочется и попробовать

[crypto5]

У меня не глючит, у Крипто5 не глючит, у тебя глюкнула - (а) ну бывает, у меня Эклипс и на GWT глюкался (б) не факт, что это Скала плагин виноват.

Да понятно, что не свезло и не факт, что вина именно Скалы. Но осадок-то остался. Как-то все immature, не смотря на 9-летний возраст.
А краткий экскурс по самому языку мне скорее понравился, чем нет. Не могу еще сообразить, понравится ли на нем писать, но отторжения не вызывает, а что-то хочется и попробовать

Можно еще idea попробовать заюзать. Бытует мнение что у нее лучше поддержка скалы.

[АццкоМото]

Можно еще idea попробовать заюзать. Бытует мнение что у нее лучше поддержка скалы.

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

[Интеррапт]

А краткий экскурс по самому языку мне скорее понравился, чем нет. Не могу еще сообразить, понравится ли на нем писать, но отторжения не вызывает, а что-то хочется и попробовать

А что там может не понравится? Та же Джава, только с дополнительными удобствами.

[АццкоМото]

А краткий экскурс по самому языку мне скорее понравился, чем нет. Не могу еще сообразить, понравится ли на нем писать, но отторжения не вызывает, а что-то хочется и попробовать

А что там может не понравится? Та же Джава, только с дополнительными удобствами.

Там может непонравиться изобретение велосипеда там, где все и так нормально. Начерта эти дурацкие def? Начерта => ? Да даже чем фигурные скобки или точки-с-запятой не устраивали, не понятно. Можно было чуть более традиционно подойти

[Интеррапт]

Вот если бы было такое чудо, я бы двумя руками его пожал (условный псевдойызык, сам с него ржу)

Это ты правильно ржешь. Не хотел бы я работать с языком, где можно обьявить переменную виртуальной.

[crypto5]

А краткий экскурс по самому языку мне скорее понравился, чем нет. Не могу еще сообразить, понравится ли на нем писать, но отторжения не вызывает, а что-то хочется и попробовать

А что там может не понравится? Та же Джава, только с дополнительными удобствами.

Там может непонравиться изобретение велосипеда там, где все и так нормально. Начерта эти дурацкие def? Начерта => ? Да даже чем фигурные скобки или точки-с-запятой не устраивали, не понятно. Можно было чуть более традиционно подойти

Фигурные скобки вроде есть, а точки с запятой опциональны. А что с => не так? Что там вместо него по классике должно быть?

[Интеррапт]

Начерта => ?

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

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

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

[M. Ridcully]

Извините, но в Java нет структур (в их Сишном понимании). Есть только классы.

Хмм, ну тогда бы это меня беспокоило бы намного больше, чем отсутствие геттеров-сеттеров.
Хотя, можно притвориться что есть 2 типа классов - собственно классы и классы-структуры.

Ссылочку можно на то, что класс с данными, но без логики - это anti-pattern?

Ссылка на что вас устроит? Если какой-нить Знаменитый Гуру Вася Пупкин скажет, что это anto-pattern - то это лично для вас что-то изменит?

Мне логики хватает. Логика примерно такая, что программа должны что-то _делать_, т.е. она принимает входные данные, чего-то с ними делает, и выплёвывает результат. Соответственно написание статичного кода, который просто тупо занимает ячейки памяти - какой в нём смысл?

[АццкоМото]

Вот если бы было такое чудо, я бы двумя руками его пожал (условный псевдойызык, сам с него ржу)

Это ты правильно ржешь. Не хотел бы я работать с языком, где можно обьявить переменную виртуальной.

Это тебе так кажется. Было бы в разы удобнее - потому что символ "=" в стопицот раз более читаем для гетов и сетов, чем дебильное getVariable()
На слове "virtual" не настаиваю. На самом деле все, что нужно - некое обозначение, могут ли подклассы переопределить методы доступа к переменной или нет. Все. Существование геттеров и сеттеров в явном виде это какой-то атавизм, как и присутствие названия переменной в в имени методов - ДВАЖДЫ

[АццкоМото]

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

Ох уж прямо и стандарт. В С++11 с квадратными скобками живут и не жужжат
() => someCrap()
легко можно заменить на
() { someCrap(); }
или даже на
{ someCrap(); } ()
будет в разы приличнее и привычнее

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

нуууу. как сказать
вот копи-пейст
override def toString() =
"" + re + (if (im < 0) "" else "+") + im + "i"
меня это выбешивает. где начало, где конец - поди разбери. пицот лет обсуждали, что лучше писать if (0==i), чем if (i==0), что имеет смысл лишний раз фигурные скобки поставить, когда пишешь
if (crap)
return other_crap;
а тут такие перцы решили сэкономить. я представляю, сколько хреново обнаруживаемых на глаз багов будет

[dotcom]

Про длинные строки - это, кстати, грабля всех языков, начиная от Лиспа. Часто читаешь статью Эрлангщика с одной строкой килобайт длинной и подпись внизу "ну вот как тут легко видно...". И тут же хочется заорать: "Как!? Где!?". Я, наверное, никогда не привыкну к функциональному коду. Поэтому, возможно, я и лямбды, кложуры и блоки ненавижу. Читаешь в столбик и тут бац! все в ширину идет.

[crypto5]

Про длинные строки - это, кстати, грабля всех языков, начиная от Лиспа. Часто читаешь статью Эрлангщика с одной строкой килобайт длинной и подпись внизу "ну вот как тут легко видно...". И тут же хочется заорать: "Как!? Где!?". Я, наверное, никогда не привыкну к функциональному коду. Поэтому, возможно, я и лямбды, кложуры и блоки ненавижу. Читаешь в столбик и тут бац! все в ширину идет.

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

[dotcom]

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

Не спорю. Можно. Хотя в функции писать, все эти pattern matching с кучей параметров, фиг отформатируешь.