LINUX.ORG.RU

Google представляет Go

 , , ,


0

0

Go — экспериментальный язык програмирования, разработанный в Google. Основные разработчики языка — Роб Пайк и Кен Томпсон, также известные как разработчики unix и plan9.

Go предназначен в первую очередь для написания крупных серверных приложений и способен сократить время сборки с десятков минут до нескольких секунд (в сравнении с C++) за счет системы модулей и явного указания зависимостей.

В языке отсутствуют классы, исключения, метапрограммирование и ручное управление памятью, однако присутствуют указатели, сборщик мусора и goto. Также на уровне языка поддерживаются легковесные процессы (goroutines) и каналы (channels).

Можно использовать фигурные скобки и юникод в идентификаторах.

>>> Подробности

★★★

Проверено: hibou ()
Ответ на: комментарий от pazak

> Без типизации, ООП ненужен.

для протокола: ООП возможен при динамической типизации

однако я не верю в нее :-)

> вершины ООП С++.

если раньше "вершиной" считалось ООП, то сейчас это полиморфизм и зависимые типы, и поэтому в различных поучениях по с++ постоянно напоминают "лучше юзайте шаблоны, а не наследование"

ну и еще -- без отвергнутых концептов из с++0х говорить о плюсах как о вершине несколько... ммм... не очень

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от pazak

> Полиморфизм это тот самое, без чего просто нет ООП.

Разумная точка зрения. Но почему вы не замечаете, что для полиморфизма не нужно наследование?

> Если нет строгой типизации, ненужен ООП, и полиморфизм в том числе.

Хихи. Дактайпинг - это, по вашему, не полиморфизм?

yk4ever
()
Ответ на: комментарий от pazak

> Ага, щаз ... привожу пример: язык lua.

Позвольте спросить, это пример чего?

yk4ever
()
Ответ на: комментарий от Absurd

>Что с CLOS не так?

http://en.wikipedia.org/wiki/Common_Lisp_Object_System

"CLOS does not enforce encapsulation. Any slot can be accessed using the slot-value function or via (optionally auto-generated) accessor methods. To access it via slot-value you have to know the name of the slot. CL programmers use the language's package facility to declare which functions or data structures are intended for export."

То-есть ничего кроме удобства в виде модульности данная надстройка не несёт. И заставить её использовать сам язык не может. Нет в языке таких средств. Это как COM для C. Недо-ООП с кучей удобства и шикарным кийвордом для булшитбинго. Просто необходимая фича (я кийворд ООП имею в виду), лет эдак 10 назад для того чтобы пролезть в энтерпрайз.

Ах да !!!! Есть ! Есть оправдание для существования всяких CLOS и COM ! Reusability и поддержка производителя либо стандарта. То-есть куча бесплатного сахара, для любого кодера. Всё логично вроде.

И незабываем, тема была о языке и средствах ООП в самом языке а не о библиотеках, надстройках и сервисах.

pazak
()
Ответ на: комментарий от www_linux_org_ru

> З.Ы. гораздо проще сделать из класса неймспейс, сделав класс открытым в области статических полей и методов, тогда можно будет сказать, что неймспейс есть частный случай класса

У вас просто проблема с русским языком. Вы неверно понимаете словосочетание "частный случай". Класс представляет собой частный случай неймспейса потому, что КАЖДЫЙ класс ЯВЛЯЕТСЯ неймспейсом. Т.е. класс = неймспейс + прочие свойства. А не наоборот.

yk4ever
()
Ответ на: комментарий от Casus

> Если я правильно понимаю одно из применений языка, то со своей сумашедшей скоростью компиляции они хотят заменить интепретируемые языки в системе.

У интерпретируемых языков, вообще-то, основные преимущества в отсутствии типизации. Скорость компиляции - это просто приятный бонус.

yk4ever
()
Ответ на: комментарий от volh

> Хорошему танцору, как известно, не мешают.

Под хорошими танцорами вы подразумеваете индусов, которые пишут спагетти? Да им вообще ничего не мешает, они простые парни по жизни.

yk4ever
()
Ответ на: комментарий от pazak

> Для сведения: реализуя интерфейс, вы, несмотря на ваше отрицание данного факта , его наследуете :)

Лучше наоборот сказать: наследуясь от базового класса, вы реализуете его интерфейс.

Теперь понятно?

yk4ever
()
Ответ на: комментарий от www_linux_org_ru

Эт уже переливание из пустого в порожнее. Одно и то-же. Статический тайпчек во время компиляции и полиморфизм основаный на использовании тэмплейтов как у Александреску к примеру, ничего мною сказаного не отменяет. Суть остаётся та-же. Вобщем мы, я думаю друг друга поняли.

pazak
()
Ответ на: комментарий от pazak

> и вершины ООП С++.

Я-то всегда думал, что вершиной ООП считается смоллтолк. Весьма динамический, кстати.

yk4ever
()
Ответ на: комментарий от yk4ever

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

kristall ★★
()
Ответ на: комментарий от pazak

>"CLOS does not enforce encapsulation. Any slot can be accessed using the slot-value function or via (optionally auto-generated) accessor methods. To access it via slot-value you have to know the name of the slot. CL programmers use the language's package facility to declare which functions or data structures are intended for export."

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

>You might actually feel _unsafe_ in a CLOS world where people are just expected to show good taste, unless you feel you can trust them. it's a matter of what kind programmers you live amongst, I guess. if you live among thieves and bums who steal and rob you, by all means go for the compiler who smacks them in the face. if you live among nice people who you would _want_ to worry about a red-hot plate they can see inside a kitchen window or a broken window they need to look inside your house before reporting as a crime (serious bug), you wouldn't want the kind of armor-plating that you might want in the 'hood. that doesn't mean the _need_ for privacy is any different. it's just that in C++ and the like, you don't trust _anybody_, and in CLOS you basically trust everybody. the practical result is that thieves and bums use C++ and nice people use CLOS.

Absurd ★★★
()
Ответ на: комментарий от yk4ever

> У вас просто проблема с русским языком. Вы неверно понимаете словосочетание "частный случай". Класс представляет собой частный случай неймспейса потому, что КАЖДЫЙ класс ЯВЛЯЕТСЯ неймспейсом. Т.е. класс = неймспейс + прочие свойства. А не наоборот.

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

yk4ever> Вы в каких-то диких терминах мыслите - "приятно видеть классы". Вам что от ООП нужно? Нэймспейсы?

pazak> ООП неймспейсами даже не начинается, не то-что не заканчивается.

yk4ever> Класс - частный случай нэймспейса. Вы не знали?

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от yk4ever

> Хихи. Дактайпинг - это, по вашему, не полиморфизм?

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

pazak
()
Ответ на: комментарий от www_linux_org_ru

> Абсурд иногда говорит интересное, но бывает на почве ненависти к плюсам его заносит в полный бред.

Carthago delenda est :]

yk4ever
()
Ответ на: комментарий от kristall

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

бОльшая часть -- дети шудр

и видел я кривые индийские поделки

разница не столько в образовании, а в попытках задуматься "а не чушь ли я пишу"; образование, однако, этому способствует

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

Моя точка зрения такая. ООП представляет собой причудливую смесь нескольких более простых концепций (модульность, нэймспейсы, диспетчеризация). Когда кто-то говорит, что ООП - это удобно, ему на самом деле просто нравятся некоторые их этих составляющих его концепций. Все они в Go, вобщем-то, есть. Поэтому он ООП-языкам ни в чём не проигрывает.

Ну кроме параметризованных типов, но это уже не совсем классика ООП.

yk4ever
()
Ответ на: комментарий от Absurd

Всё может быть. Однако это не конструктивно и к спору отношения не имеет. Оно (ООП) просто либо нужно, либо нет. Это как принципом Окама ползоваться для того чтобы подтвердить или опровергнуть существование бога. При современном уровне знаний о мире , концепция бога просто ненужна, соответственно без неё можно обойтись. Так и с ООП. При жесткой типизации ООП необходим как воздух, парадигма такая. При отсутствии типизации, ООП ненужен. Модульность нужна да, а ООП ненужен. А ООП это полиморфизм, наследование, инкапсуляция. Классика мазохизма.

pazak
()
Ответ на: комментарий от pazak

> то да наверное полиморфизм.

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

Пойдём дальше. Вы уже готовы осознать, что полиморфизм - частный случай декларативной диспетчеризации по типу с приоритетом первого аргумента? Знакомы с Dylan/CLOS/Haskell достаточно, чтобы осознать импликации подобного обобщения?

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

И вам тоже следует отказаться от использования notepad.exe для работы.

yk4ever
()
Ответ на: комментарий от pazak

> При жесткой типизации ООП необходим как воздух, парадигма такая.

Снова: Haskell?

> А ООП это полиморфизм, наследование, инкапсуляция.

Мне эта мантра из трёх слов уже так надоела. Все их повторяют, но никто не хочет понимать что они значат на самом деле.

yk4ever
()
Ответ на: комментарий от pazak

>При жесткой типизации ООП необходим как воздух, парадигма такая.

Вот так новость. Где же ООП в Haskell?

kristall ★★
()
Ответ на: комментарий от yk4ever

>> Для сведения: реализуя интерфейс, вы, несмотря на ваше отрицание данного факта , его наследуете :)

>Лучше наоборот сказать: наследуясь от базового класса, вы реализуете его интерфейс.

>Теперь понятно?

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

Это типа такой метод звездатость заработать ? :)

pazak
()
Ответ на: комментарий от yk4ever

> Класс представляет собой частный случай неймспейса потому, что КАЖДЫЙ класс ЯВЛЯЕТСЯ неймспейсом. Т.е. класс = неймспейс + прочие свойства. А не наоборот.

Каждый кот является усатым существом -> усатые существа == частный случай котов, т.е. каждое усатое существо это кот + прочие свойства

anonymous
()
Ответ на: комментарий от yk4ever

>но никто не хочет понимать что они значат на самом деле.

Дак может слова и идеи стоящие за этими словами не очень удачные, раз все их повторяют, но никто не хочет понимать что они означают? Откуда такое самомнение у создателей ООП, что их подход на века и единственно верный?

kristall ★★
()
Ответ на: комментарий от yk4ever

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

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

наследование = причудливые^W специфичные параметризованные типы + диспетчеризация

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от anonymous

Каждый кот является усатым существом -> усатые существа == частный случай котов, т.е. каждое усатое существо это кот + прочие свойства

:) Точно. Хоть с мнением автора я и согласен, логика у него именно такая :)

Ximen ★★★★
()
Ответ на: комментарий от yk4ever

> Ну кроме параметризованных типов, но это уже не совсем классика ООП.

Чушь. Это уже давно стало классикой. Со времен Алексеева и принятия STL в стандарт языка C++. А уж после откровений Александреску, генерики стали святым базисом C++.

pazak
()
Ответ на: комментарий от anonymous

> Каждый кот является усатым существом -> усатые существа == частный случай котов, т.е. каждое усатое существо это кот + прочие свойства

Неверно. Иосиф "Сталин" Джугашвили - усатое существо, но вовсе не кот.

Куда вы с такими дефектами логики в языкосрач лезете? Марш в школу.

yk4ever
()
Ответ на: комментарий от yk4ever

> Вы уже готовы осознать, что полиморфизм - частный случай декларативной диспетчеризации по типу с приоритетом первого аргумента?

неверно

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от pazak

> Это типа такой метод звездатость заработать ? :)

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

yk4ever
()
Ответ на: комментарий от yk4ever

>Неверно. Иосиф "Сталин" Джугашвили - усатое существо, но вовсе не кот.

Строго говоря - замечание верное. Но псевдоним Сталин - происходит от фамилии переводчика "Витязь в тигровой шкуре" -Сталина, любимой книги Джугашвили в юности. Поэтому при нечеткой логике можно отнести Витязя (коль скоро он в тигровой шкуре) к котам. А следовательно и Сталина. Что и было отмечено К. Юнгом при анализе личности диктатора.

kristall ★★
()
Ответ на: комментарий от kristall

> Откуда такое самомнение у создателей ООП, что их подход на века и единственно верный?

Да говно подход. Это уже всем известно.

http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

Только pazak'у нашему промыли бошку буллщитом, вот он и голосит тут до сих пор.

yk4ever
()
Ответ на: комментарий от Ximen

> :) Точно. Хоть с мнением автора я и согласен, логика у него именно такая :)

Вы тоже очень невнимательны. Обратитесь к офтальмологу, возможно пора менять очки.

yk4ever
()
Ответ на: комментарий от yk4ever

> Вы уже готовы осознать, что полиморфизм - частный случай декларативной диспетчеризации по типу с приоритетом первого аргумента?

Ну, если уж на то пошло, то диспатч идет исключительно по первому аргументу, без приоритетов. В этом смысле CLOS помощнее будет.

faustus
()
Ответ на: комментарий от yk4ever

> Вы уже готовы осознать, что полиморфизм - частный случай декларативной диспетчеризации по типу с приоритетом первого аргумента?

наверно, правильно будет так:

в нищебродских языках с динамической проверкой типов ad-hoc полиморфизм -- частный случай декларативной диспетчеризации по типу с приоритетом первого аргумента

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от pazak

> Чушь. Это уже давно стало классикой.

Ну тогда скажите, в каком месте это входит в вашу мантру "наследование, инкапсуляция, полиморфизм"? Или всё-таки Generic Programming есть надстройка над ООП?

yk4ever
()
Ответ на: комментарий от www_linux_org_ru

> наследование = причудливые^W специфичные параметризованные типы + диспетчеризация

Эммм, не вижу связи между параметризованными типами и наследованием. НИКАКОЙ.

yk4ever
()
Ответ на: комментарий от faustus

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

Неа. Сначала по первому, а потом ещё может по перегрузкам методов. Короче, сам чёрт ногу сломит.

> В этом смысле CLOS помощнее будет.

Не только мощнее, но чётче и правильнее. CLOS, Dylan и Haskell. "OOP done right"

yk4ever
()
Ответ на: комментарий от yk4ever

>Неверно. Иосиф "Сталин" Джугашвили - усатое существо, но вовсе не кот.

Усы, 1 голова, 4 конечности (с доп свойствами, отличающими их от лап: меньшая плотность шерсти, слегка так другая форма и размер), шерсть на теле присутствует (мужик всётаки, да ещё и грузин).
Всё как у котов, но с доп свойствами.
Ну способность говорить по-человечески - тоже доп свойство и всё такое.

anonymous
()
Ответ на: комментарий от yk4ever

Вы тоже очень невнимательны. Обратитесь к офтальмологу, возможно пора менять очки.

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

PS: очков не было нет и не будет. ;)

Ximen ★★★★
()
Ответ на: комментарий от yk4ever

> Ну тогда скажите, в каком месте это входит в вашу мантру "наследование, инкапсуляция, полиморфизм"? Или всё-таки Generic Programming есть надстройка над ООП?

полиморфизм, который в изначальном определении ООП понимался исключительно ad hoc, бывает также и параметрическим, и таким поддерживается в плюсах

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> в нищебродских языках с динамической проверкой типов

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

yk4ever
()
Ответ на: комментарий от yk4ever

> А хвост? А когти?

Хвост у человека тоже есть тока ооочень маленький - копчик там ещё рядом ага.
Когти/ногти тоже в наличии.
Всё в наличии.

anonymous
()
Ответ на: комментарий от www_linux_org_ru

> полиморфизм, который в изначальном определении ООП понимался исключительно ad hoc, бывает также и параметрическим, и таким поддерживается в плюсах

Вот видите, как всё сложно с этим ООП. Каждый его как хочет, так и трактует. Кому-то обязательно наследование, кому-то генерики, а кто-то без этого всего обходится.

yk4ever
()
Ответ на: комментарий от yk4ever

> Эммм, не вижу связи между параметризованными типами и наследованием. НИКАКОЙ.

для простоты объяснения возьмем множетвенное наследование (МН)

операция МН переводит упорядоченную пару (Тип1, Тип2) в тип-наследник, который может быть записан (в плюсах) как МН<Тип1,Тип2> и представляет собой новый тип, параметризованный старыми Тип1,Тип2

а еще полезно разобраться, ко- или контра-вариантен новый тип по своим параметрам

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Absurd

> Такая вещь как дженерики и связывание символа с реализацией должны относиться скорее к платформе, а не языку. А на уровне платформы их реализовать нельзя. Дотнет не смотрел, но ожидание чуда невелико.

У .NET с дженериками всё же лучше чем у жабы - там на уровне байткода сохраняется тип которым класс параметризован.

Darkman ★★★
()
Ответ на: комментарий от yk4ever

>> в нищебродских языках с динамической проверкой типов

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

в языках со статической проверкой типов виртуальный метод *может* быть использован для динамической проверки, однако это не значет, что он *является* динамической проверкой типа

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.