Чой-то в последние дни со временем для писательства туговато, поэтому просто озвучу несколько новостей и ссылок.
Джеймс Гослинг, автор языка Java, некоторое время назад уволившийся из поглотившего Sun Oracle, теперь работает в Google: http://nighthacks.com/roller/jag/entry/next_step_on_the_road (похоже, сейчас сайт Гослинга в дауне из-за наплыва посетителей, найти короткую заметку без особых подробностей можно в кэше Google).
Так что Гослинг нонче в Google. Почему-то я этому совсем не удивлен. Надеюсь, к развитию Go его не допустят :)
Вышел первый релиз-кандидат версии 2.9.0 языка Scala. Из основных нововведений отмечается появление parallel collections и какой-то “Generalized try-catch-finally” (поскольку Scala я уже основательно подзабыл, то не очень понимаю в чем фишка – управление исключениями в Scala было же изначально).
Вышел GCC 4.6.0 (здесь список изменений). А я узнал про существование еще одного дистрибутива GCC/MinGW для Windows под названием TDM-GCC. Пока не пробовал, но надеюсь, что ставить его проще чем скачивать отдельные MinGW-шные архивы (как мне приходилось делать это раньше). И, кстати говоря, появились версии GDC (компилятора языка D для GCC) под TDM-GCC.
> Так что Гослинг нонче в Google. Почему-то я этому совсем не удивлен. Надеюсь, к развитию Go его не допустят :)
ОтветитьУдалитьБоитесь за Гослинга или за Гоу?
PS: В GCC 4.6 кстати уже есть Go-фронтэнд
ОтветитьУдалить> Надеюсь, к развитию Go его не допустят :)
ОтветитьУдалитьЯ тоже. Одна пром.-тулза на нём уже.
@Left:
ОтветитьУдалитьБоюсь за Go. А то Гослинг себя зарекомендовал как разработчик языков, которыми пользоваться просто, но неприятно.
@buffovich:
ОтветитьУдалитьВ смысле написанная и внедренная тобой промтулза?
Сейчас для MinGW уже есть инсталлятор.
ОтветитьУдалить@yuhala:
ОтветитьУдалитьСпасибо, не знал.
>просто, но неприятно.
ОтветитьУдалитьПочему неприятно, с хорошей IDE - очень даже приятно.
@xonix:
ОтветитьУдалитьХорошая IDE упрощает набор программ на Java, но не их написание (проектирование).
> Хорошая IDE упрощает набор программ на Java, но не их написание (проектирование).
ОтветитьУдалитьНабор и написание вроде как одно и то же.
Хорошая IDE рулит со страшной силой когда нужно разобраться в том как что-то работает или поменять спроектированное решение (читай - зарефакторить).
>Хорошая IDE упрощает набор программ на Java, но не их написание (проектирование).
ОтветитьУдалитьА можете пояснить разницу? Я думал, проектирование вообще делается отдельно, например в UML.
@Left:
ОтветитьУдалить>Хорошая IDE рулит со страшной силой когда нужно разобраться в том как что-то работает или поменять спроектированное решение (читай - зарефакторить).
С этим я спорить не буду, я о другом говорил.
@xonix:
ОтветитьУдалить>А можете пояснить разницу?
Ну вот нужна мне в нескольких классах какая-нибудь однострочная вспомогательная функция для преобразования даты/времени в строчку хитрого формата. На C++ или в Ruby я сделаю ее обычной свободной функцией. А в Java нужно создавать какой-нибудь утилитный класс, в котором эта функция будет статическим членом. И так слишком часто -- очень много приседаний нужно делать. IDE облегчает их выполнение, но не особождает от них.
Более подробно на тему Java я когда-то писал:
http://eao197.blogspot.com/2010/04/progflame-java-i.html
http://eao197.blogspot.com/2010/04/progflame-java-ii-java.html
http://eao197.blogspot.com/2010/04/progflame-java-iii-java.html
http://eao197.blogspot.com/2010/05/progflame-java-v-ide.html
>Я думал, проектирование вообще делается отдельно, например в UML.
Не-не-не :) UML -- это только нотация для записи проектных решений.
> А в Java нужно создавать какой-нибудь утилитный класс, в котором эта функция будет статическим членом.
ОтветитьУдалитьА в джава с IDE я напишу её по месту (прямо там где она нужна) а потом нажатием пары комбинаций клавиш сделаю её сначала отдельной функцией а потом - функцией в утилитном классе
@Left:
ОтветитьУдалитьТак вот я и говорю -- количество приседаний не уменьшается, просто делать их с IDE становится проще.
> Так вот я и говорю -- количество приседаний не уменьшается, просто делать их с IDE становится проще.
ОтветитьУдалитьПриседания - это нажатия клавиш, или количество умственных усилий. Пофиг что именно - их реально становится меньше.
@Left:
ОтветитьУдалить>Приседания - это нажатия клавиш, или количество умственных усилий. Пофиг что именно - их реально становится меньше.
Не-а, приседания -- это количество сущностей, которые приходится плодить в программе. Да, плодить их проще. Но лучше было бы не плодить вовсе.
И, имхо, Go как раз язык, в котором (пока?) лишних сущностей плодить не приходится из-за приверженности авторов языка к какой-то доминирующей парадигме (как было в Java с ООП).
> Не-а, приседания -- это количество сущностей, которые приходится плодить в программе. Да, плодить их проще. Но лучше было бы не плодить вовсе.
ОтветитьУдалитьЭто компенсировано отсутствием тех самых лишних сущностей в самом языке. И, с моей т.з., именно это плюс, потому что код получается более регулярен.
Я считаю, что все что может быть реализовано библиотеками, не имеет права быть встроено в синтаксис языка (например хмл, регулярные выражения и т.д.). Java не случайно так популярна, что гармонично построена из действительно необходимых сущностей. Необдуманная попытка добавить новые сущности в язык может привести к отрицательному результату.
> И, имхо, Go как раз язык, в котором (пока?) лишних сущностей плодить не приходится из-за приверженности авторов языка к какой-то доминирующей парадигме (как было в Java с ООП).
А в Go нету исключений, имхо большой минус. Это та сущность, которую никак не назовешь лишней.
> А в Go нету исключений, имхо большой минус. Это та сущность, которую никак не назовешь лишней.
ОтветитьУдалитьНу т.е. то что в Гоу нету наследования в привычном понимании Вас не напрягает, а по исключениям льёте слёзы? ;) Исключения в Гоу не нужны - есть гоурутины и есть паники, отличная замена.
@xonix:
ОтветитьУдалить>Это компенсировано отсутствием тех самых лишних сущностей в самом языке. И, с моей т.з., именно это плюс, потому что код получается более регулярен.
Ну вот мне в Java не хватает таких вещей из C++, как указатели на методы (а из C указатели на функции), указатели на члены класса. Не говоря уже про свободные функции, перегрузку операторов, шаблоны функций. Из того же Ruby не хватает лямбда-функций и примесей. Это все вещи, которые библиотеками не о хватишь. В отличии от XML или Regexp-ов.
А так, уж простите мне мою нелюбовь к Java, как язык он регулярно примитивен.
@xonix
ОтветитьУдалить>А в Go нету исключений, имхо большой минус.
На эту тему здесь уже пофлеймили:
http://eao197.blogspot.com/2010/10/progflame-d-go.html
http://eao197.blogspot.com/2010/10/progflame-go-defer-panic-recover.html
По-моему, исключения лучше. Но, в любом случае, паники в Go дают разработчикам хорошие механизмы, которые позволяют писать надежные программы (как раз цель исключений).
> Ну вот мне в Java не хватает таких вещей из C++, как указатели на методы (а из C указатели на функции)
ОтветитьУдалитьЕсть мнение, что отсутствие этих вещей приводит к более type-safe коду. Я имею в виду, что вы не вставите Runnable туда где принимается, например, Callable. Лично мне кажется, это хорошо.
> перегрузку операторов
Это облегчит набор кода в блокноте, но усложнит в IDE. Сейчас все операции надо объектом можно узнать написав "obj." и получив выпадающий список со всеми методами. А с операторами, индексаторами, и прочими "полезностями" это будет не так прямолинейно (и регулярно).
> шаблоны функций
Ну шаблонные методы есть, типа такого:
http://download.oracle.com/javase/tutorial/extra/generics/methods.html
Впрочем, Вы правы, что это не работает для примитивных типов.
@xonix
ОтветитьУдалить>Есть мнение, что отсутствие этих вещей приводит к более type-safe коду.
Я не разделяю это мнение. Поскольку:
a) указатель на метод привязывается к конкретному типу. Т.е. если у вас есть void Runable::*m() и void Callable::*m(), то они не совместимы между собой (если только классы не унаследованы друг от друга);
b) широкое использования лямбда-функций в функциональных языках программирование показывает, что type-safety вообще не страдает. Даже не смотря на то, что там к лямбде типа void launch() можно привязать как метод Process.launch, так и NuclearMissle.launch.
>Это облегчит набор кода в блокноте, но усложнит в IDE.
AFAIK, в C# есть перегрузка операторов, но инструментами вроде VisualStudio и Resharper-а народ пользуется без проблем.
Помимо TDM-GCC, есть еще одна сборка под windows: http://nuwen.net/mingw.html
ОтветитьУдалитьp.s.
Вот еще есть хорошая новость:
EiffelStudio 6.8.x Changelog
compiler: Added SCOOP support for Windows and Linux.
За этой строкой из списка изменений стоит огромная многолетняя работа.
@Quaker:
ОтветитьУдалитьспасибо за информацию. SCOOP в составе компилятора -- это сильно, молодцы. Сомневаюсь, правда, что это сможет оказать более-менее серьезное влияние на индустрию. Поздновато, имхо. Но молодцы, что допилили.