LINUX.ORG.RU

Брюс Эккель признался в бессилии


0

0

I'm the first to admit that I'll probably never be able to create a correct threaded program in C++ or Java, despite years of study. It's just too hard.

Я первый признаЮсь, что не смогу написать корректную мультипоточную программу ни на C++, ни на Java, несмотря на годы, которые я провел, обучая тысячи людей этим языкам программирования. Это за пределами моих возможностей.

Что уж говорить об "обычных программистах на C++"?

Об этом и многом другом говорит Брюс Эккель, рассуждая о языках Python 2.9 и Python 3000.

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

anonymous

Проверено: anonymous_incognito ()

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

А чего? Дядька зарабатывает деньги обясняя что очередной язык про который он написал книгу мегарулез. А книги он пишет по накатанной схеме - читает тутор и переписывает под план предидущей книги.

Если зайдешь на сайт посмотришь что следующее что он будет пиарить - это C#. И обяснять всем как он был неправ думая что можно написать нормальную лямбду на питоне.

Эккель потерял все мое уважение как только написал статью что динамическая типизация лучше статической "потому-что не нужно обявлять интерфейсы и типы переменных". Фую

r ★★★★★
()

А я каждый день создаю корректные мультипоточные программы на Си++. Но не в состоянии обучить этому.

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

> которые я провел, обучая тысячи людей этим языкам

+1 слишком вольный перевод :)

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

> - Support for DSL Creation. Не совсем понял, может кто обьяснит?

Поддержка создания языков предметной области на основе языка программирования. http://en.wikipedia.org/wiki/Domain-specific_programming_language . Можно привести примеры языков в которых это делается легко и изящно: Lisp и Ruby.

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

> Я надеюсь/подозреваю, что erlang написан на C/C++? Если так, то все тоже самое возможно и для самих C/C++.

Не совсем всё так просто. Для того, чтоб легко и элегантно создавать процессы, пришлось придумать новый язык с новым синтаксисом и семантикой. Если то же самое сделать в виде библиотеки для C++, получится чудище вроде чуть выше упомянутого SObjectizer.

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

Не могу удержаться, чтоб не запостить hello world для SObjectizer.

Это код создаёт один процесс («агент»), который обрабатывает одно
событие и выводит "Hello, world!". Это просто песня: 

#include <iostream>

// Загружаем основные заголовочные файлы SObjectizer.
#include <so_4/rt/h/rt.hpp>
#include <so_4/api/h/api.hpp>

// Загружаем описание нити таймера и диспетчера.
#include <so_4/timer_thread/simple/h/pub.hpp>
#include <so_4/disp/one_thread/h/pub.hpp>

// C++-описание класса агента.
class  a_hello_t
  : public so_4::rt::agent_t
{
  // Псевдоним для базового типа.
  typedef so_4::rt::agent_t base_type_t;
  public :
    a_hello_t()
    :
      // Сразу задаем имя агента.
      base_type_t("a_hello")
    {}
    virtual ~a_hello_t()
    {}

    virtual const char *
    so_query_type() const;

    virtual void
    so_on_subscription()
    {
      // Нужно подписать наше единственное событие.
      so_subscribe("evt_start",
        so_4::rt::sobjectizer_agent_name(),
        "msg_start");
    }

    // Обработка начала работы агента в системе.
    void
    evt_start()
    {
      std::cout << "Hello, world!" << std::endl;

      // Завершаем работу примера.
      so_4::api::send_msg(
        so_4::rt::sobjectizer_agent_name(),
        "msg_normal_shutdown", 0);
    }
};

// Описание класса агента для SObjectizer-а.
SOL4_CLASS_START(a_hello_t)

  // Одно событие.
  SOL4_EVENT(evt_start)

  // И одно состояние.
  SOL4_STATE_START(st_normal)
    // С одним событием.
    SOL4_STATE_EVENT(evt_start)
  SOL4_STATE_FINISH()

SOL4_CLASS_FINISH()

int
main()
{
  // Наш агент.
  a_hello_t a_hello;
  // И кооперация для него.
  so_4::rt::agent_coop_t  a_hello_coop(a_hello);

  // Запускаем SObjectizer Run-Time.
  so_4::ret_code_t rc = so_4::api::start(
    so_4::disp::one_thread::create_disp(
      so_4::timer_thread::simple::create_timer_thread(),
      so_4::auto_destroy_timer),
    so_4::auto_destroy_disp,
    &a_hello_coop);
  if(rc) {
    // Запустить SObjectizer Run-Time не удалось.
    std::cerr << "start: " << rc << std::endl;
  }

  return int(rc);
}

ero-sennin ★★
()
Ответ на: комментарий от Valeriy_Onuchin

> странно, почему Брюс Эккель не вспоминает об erlange, а говорит о Scala http://www.scala-lang.org/ хотя, я так понимаю, что там тот же AJAX-style-programming.

Видимо, потому что Scala работает на JVM. :)

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

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

Глупый человек, ну зачем ты споришь ? Я же указал абстрактное обоснование для необходимости разделяемой сущности. И архитектуры тут не причем. Смотри - предположим, что две сущности полностью изолированны друг от друга (не содержат ничего общего), эти сущности/системы по уже заданому требованию являются замкнутыми и изолированными по отношению друг другу, а значит не могут обмениваться ___ничем___. Если допустить существование святого духа, то все отлично, но если нет , то ответте на вопрос - как информация преодолеет барьер между системами, с помощью магических заклинаний?

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

>> Ещё раз повторю. Работать вручную с разделяемой памятью для человека противоестественно. Также, как и писать сложный код на машинном языке. Такое желание уместно в период полового созревания, но с возрастом обычно проходит. Не надо делать за машину её работу, потому что человеческий труд обходится гораздо дороже.

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

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

>Нисколько не хочу принизить питон, но хотелось бы узнать, что такого особенного он предлагает в плане многопоточности?

На жабе или с++ можно долго мучиться, но так и не написать многопоточную программу.

А на питоне достаточно пары часов, чтобы понять, что писать на нем многопоточные программы вообще нереально.

AVL2 ★★★★★
()
Ответ на: комментарий от ero-sennin

> Не могу удержаться, чтоб не запостить hello world для SObjectizer.

Вот заодно пример на Эрланге:

-module(helloworld).

-export([hello/0]).
-export([start/0]).

hello() ->
    receive
        say_hello ->
            io:format("Hello world~n", [])
    end.

start() ->
    Hello_PID = spawn(helloworld, hello, []),
    Hello_PID ! say_hello.

ero-sennin ★★
()
Ответ на: комментарий от tailgunner

>> что-бы потоки обменялись хоть чем-то (блокировкой, сообщением и тд...), нужно что-бы у них была хоть какая-то общая часть

> ИМХО, ты поменял местами причину и следствие. Нити по определению исполняются в общем адресном пространстве. Они не обязаны общаться через общую память (могут хоть через TCP-сокеты), но через общую память - самое практичное.

Е мое, сокеты где ? в ядре. А ядро ? - __общая разделяемая сущность__.
А для ядра все процессы находятся в __общей разделяемой памяти__

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

> А на питоне достаточно пары часов, чтобы понять, что писать на нем многопоточные программы вообще нереально.

Почти согласился бы, если бы не stackless.

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

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

Да! даже если ты разделяешь 1 бит порта ввода вывода - ты уже разделяешь общую память.
И это не вопрос терминологии. Это принципиальный вопрос. Вы пытаетесь свести проблему к чуши - общей разделяемой памяти, хотя Вам уже привели Дейкстру, который указал что проблема в __недетерминированности__. И это принципиальный вопрос!
Не хорошо обманывать детей :( ошивающихся на лоре :)

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

> Для того, чтоб легко и элегантно создавать процессы, пришлось придумать новый язык с новым синтаксисом и семантикой.

Семантика выражена на Си/Си++. Синтаксис... ну что ж, придется пользоваться вызовами функций и имеющимися в Си++ операторами.

> Если то же самое сделать в виде библиотеки для C++, получится чудище вроде чуть выше упомянутого SObjectizer.

SObjectizer - это всего одна библиотека, со своей историей.

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

> Е мое, сокеты где ? в ядре. А ядро ? - __общая разделяемая сущность__.

Молодец, ты заработал твёрдое "отлично" по софистике. Наверное, весь мир - это одна большая общая разделяемая память^Wсущность.

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

>Что-то у Льва Толстого никакой Бани не было.

Было-было:))) Тоглько издательство "Мир" этого не печатало :)

r ★★★★★
()
Ответ на: комментарий от ero-sennin

>> Не могу удержаться, чтоб не запостить hello world для SObjectizer.

> Вот заодно пример на Эрланге:

Разница в том, что SObjectizer это всего лишь библиотека, которая добавляет в C++ возможность агентного программирования.

Erlang же создавался в лаборатории Ericsson-а как язык для написания оказоустойчивых телекоммуникационных приложений. И прошел путь в десять лет (с 1986 по 1996) прежде чем на нем было создано первое серьезное приложение -- знаменитый благодоря рекламе Erlang-овцев свитч AXD301 (если не перепутал название). При этом только Erlang-овскую часть этого свитча писали 50 человек.

Так что не нужно сравнивать мелкое с мягким.

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

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

eao197 ★★★★★
()
Ответ на: комментарий от ero-sennin

>> http://www.sics.se/~joe/apachevsyaws.html

>Вот интересно, как бы в этом тесте себя показали lighttpd и nginx?

Увидеть бы YAWS в реальной экплуатации, там где lighttpd и nginx уже сейчас не имеют конкурентов.

А то дальше абстрактных тестов YAWS пока не ушел, AFAIK

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

>> Молодец, ты заработал твёрдое "отлично" по софистике. Наверное, весь мир - это одна большая общая разделяемая память^Wсущность.

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

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

> Кстати, если вы думаете, что ФП и Erlang в частности являются серебрянной пулей на все случаи жизни, то попробуйте на Erlang-е матрицы перемножать.

There is no silver bullet. (с) Нет дураков, чтоб использовать Эрланг для числодробильных задач. Но для всяких многопоточных и распределённых серверов — самое то.

PS Вот для распределённых числодробильных задач я до сих пор не знаю адекватной технологии.

PPS Фига себе, на ЛОРе появился предпросмотр постов! Только что заметил кнопку.

ero-sennin ★★
()
Ответ на: комментарий от r

> Было-было:))) Тоглько издательство "Мир" этого не печатало :)

"Садись, два." То был (предположительно) А.Н. Толстой, а никак не Л.Н. Толстой.

sv75 ★★★★★
()
Ответ на: комментарий от ero-sennin

> PS Вот для распределённых числодробильных задач я до сих пор не знаю адекватной технологии.

Это что за класс задач и чем они выделяются, что например MPI не годится? (я не ерничаю, а серьезно спрашиваю).

sv75 ★★★★★
()

Ещё одна рекламная акция от Брюса Эккеля.
Кстати на TheServerSide.Com он уже рекламирует Flex ;-)

Маленький эксуркс в историю, Брюс - автор плохой и довольно популярный среди недопрограммистов книги по java.
Книга даже в третьем переиздании содержит ряд концептуальных ощибок как по многопоточности так и по работе с java.io потоками.
За это автора не раз пинали авторитетные люди.
В итоге Брюс сначала бросился пиариить Python, а затем Flex.

PS
Совет читайте книги написанные людьми которые сами смогли что-то создать на языке который пишут. По многопоточности очень рекомендую Java Concurrency in Practice (by Joshua Bloch)


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

> Именно за них.

> Хорошая пропаганда, выходит, раз так батюшек торкнула :-).

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

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

> Ну, в таком случае Бруно тоже пропагандировал христианские заблуждения :-).

Бруно библию не переписывал и не говорил, что Христос просто человек, а это церкви -- сами знаете что :)

У М.Булгакова библия Толстого представлена как библия от Воланда (книга Мастера)

vadiml ★★★★★
()

>> Я первый признаЮсь, что не смогу написать корректную мультипоточную программу ни на C++, ни на Java

Сначала надо написать интерпретатор Python на C++, а затем на питоне - мультипоточную программу.

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

>>> Как уже неоднократно было говорено многими умными людьми, модель разделяемой памяти — худшее, что можно придумать для организации взаимодействия между потоками. >Без разделяемой памяти - это ___принципиально___ сделать невозможно

Опять ананимусы ацки жгут ;)

Открой для себя парадигму обмена сообщениями (MPP) и MPI как самую известную ея реализацию.

Кто из них хуже конечно еще тот вопрос ;)

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

из всех "желаний" Брюс Эккеля наиболее проблематичным (IMHO) является
сочетание "Concurrency" with "Transparent Connections to UI Languages".
Все известные (мне) GUI libs/frameworks либо не являются threadsafe
(Qt, GTK etc.), либо весь GUI processing производят в одной
thread (X11, win32, win32 COM appartments etc.)

Есть, конечно, великий и ужасный Джон Кармак, может у него есть нечто
подобное ...

Valeriy_Onuchin ★★
()
Ответ на: комментарий от ero-sennin

> PPS Фига себе, на ЛОРе появился предпросмотр постов! Только что заметил кнопку.

действительно

так вот почему около получаса назад ЛОР не отзывался

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

>> Вот для распределённых числодробильных задач я до сих пор не знаю адекватной технологии.

> PVM, MPI? :D

Уж тогда скорее OpenMP (его теперь даже вижуалка поддерживает). С помощью системных вызовов больно муторно это писать вручную, особенно на фортране :(((

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

> Да и то синод зашевелился только когда Толстой начал писать свою версию библии.

Не было такого, если я не ошибаюсь. Была своя трактовка уже написаного в духе "освободим учение Христа до ересей Петра и Павла" :)

sv75 ★★★★★
()

паскаль спасет его от полового бессилия.

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

> Уж тогда скорее OpenMP (его теперь даже вижуалка поддерживает). С помощью системных вызовов больно муторно это писать вручную, особенно на фортране :(((

А выжуалка уже поддерживает Fortran? Небосб он там называется Visual Fortran .NET? :)

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

>В статье говориться "... это тяжело" ... . Ответ - "используй пакеты ... ни о каком приемуществе Pythona, не идет речь ...

Я намекнул некоторым, что их сравнение своего уровня знаний с Еккелевым очень напоминает проявление известного психологического феномена. Причём тут, спрашивается, питон и пакеты/надстройки?

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

> PVM, MPI? :D

PVM и PMI слишком низкоуровневые, чтобы их удобно было использовать в голом виде. Распараллеливание программы с их помощью требует серьёзных трудозатрат. Да и Фортран, и С/C++ — не самые удобные языки для математики. Элементарная конструкция \sum_0^N f(x) превращается в громоздкий цикл. Элементарное выражение с теми же суммами, которое на бумаге занимает одну строчку, превращается в два экрана невразумительного кода. Кто-нибудь пробовал по чужому коду на Фортране-77 восстанавливать исходные уравнения? Вот то-то мне. ;)

В идеале хочется иметь такой спецязык, чтоб умел и с матрицами эффективно работать, и ФП там было, и встроенные примитивы для распределённых вычислений. Я когда-то в поисках такого языка весь инет перерыл, но ничего путного так и не нашёл, кроме Fortress, который тогда существовал только на бумаге, а сейчас существует только в виде интерпретатора на яве в стадии глубокой пре-альфы.

ero-sennin ★★
()
Ответ на: комментарий от DonkeyHot

> Я намекнул некоторым, что их сравнение своего уровня знаний с Еккелевым очень напоминает проявление известного психологического феномена. Причём тут, спрашивается, питон и пакеты/надстройки?

Я вовсе не считаю себя умнее Эккеля. Скорее, наоборот, надо обладать недюжинными силой ума и трудолюбием, чтоб много лет писать многопоточные программы с общими данными и не послать всё к чертям свинячим. Я же ленив и соображаю довольно туго. И однажды поимев дело с потоками и мутексами, сразу понял, что это определённо не правильный путь. Кроме шуток. :) И свято уверен, что ту работу, с которой лучше справляется машина, человеку брать на себя глупо и нелепо. Машина должна работать, человек думать.

ero-sennin ★★
()
Ответ на: комментарий от eugine_kosenko

>>> "Общая часть" != "Разделяемая память"

святой дух ?

и как вы собираетесь передать хотя бы 1 бит информации если у вас
нет разделяемого массива бит ?

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

> и как вы собираетесь передать хотя бы 1 бит информации если у вас нет разделяемого массива бит ?

Сокет не является чем-то разделяемым.

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

>Опять ананимусы ацки жгут ;)
>Открой для себя парадигму обмена сообщениями (MPP) и MPI как самую известную ея реализацию.
>Кто из них хуже конечно еще тот вопрос ;)

может я что упустил, и в MPI полность решена проблема синхронизации?

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

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