Чего Вам не хватает в С ?

make

Спасибо, Кэп

 

CyberManiac

Русского, да. А вот славянского вряд ли. Например, какое слово древнее, Ярь или Эрос?

 

Ярь

 

jabocrack
Сейчас очень распространены псевдо-научные исследования истории. Основанные в том числе на свободном манипулировании словами. Поэтому надо быть осторожными в выводах.

Количество букв в словах Эрос и Ярь или различие в их фонетическом звучании не говорит о более раннем или более позднем происхождении.

Об исторической лингвистике
академик Андрей Анатольевич Зализняк
http://elementy.ru/lib/430714

Об исторической лингвистике (продолжение)
академик Андрей Анатольевич Зализняк
http://elementy.ru/lib/430984

Некоторые проблемы порядка слов в истории русского языка
академик Андрей Анатольевич Зализняк
http://elementy.ru/lib/431049

 

x*й

тема похоже себя исчерпала (если в ней изначально что-то было)

 

skomarov
Ага. Но своим постом ты ответил CyberManiac`у. Я выводов не делал)

 

jabocrack
Мое сообщение комментирует вопрос: "какое слово древнее", но не отвечает на него, потому что я не специалист в области этимологии. По поводу истории развития языков, то я также не специалист в области лингвистики (Индоевропейские языки). Просто подумал, что ссылки на хорошие статьи будут кому-нибудь интересны.

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

http://www.unicode.org/
http://fonts.ru/public/

 

Стандартная библиотека более абстрактна, оперирует не такими низкоуровневыми сущностями, как "объекты, обменивающиеся сообщениями", а понятиями "алгоритм", "итератор", "коллекция". Вот в примере ниже ostream_iterator, можно сказать, объект. Но его состояние не имеет значения, это по факту монада. Не имеет значения и свойства элементов контейнера, негде проявиться "наследованию, инкапсуляции и полиморфизму". При чем сам алгоритм копирования, можно сказать, полиморфный, но с точки зрения функции тип ее аргументов не важен.

std::copy(s.begin(), s.end(), std::ostream_iterator<char>(std::cout));

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

Формально, да, ссылка на черновик не нормативна, но все же это есть в WG14 N1425 Committee Draft — November 24, 2009 ISO/IEC 9899:201x

 

Препишу предудущий пример, используя "вложенные функции"

std::for_each(s.begin(), s.end(), [](decltype(*s.begin()) c){ std::cout << c; });

 

Уродский синтаксис С++ )

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

 

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

 

Booster давай, но как быть с тем, что лямбда является первоклассным объектом, а функция в С++ - нет (в отличие от функторов). Поэтому, наверное, это дословно называется "лямбда-выражение" и имеет тип "замыкание"? Это было к тому что люди хотят "подфункции" в С

 

J0E

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

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

ну у каждого свой критерий читабельности. ктото ж придумал брэйнфак и бефунге? им такое читабельно вполне.

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

Код (Text):

1. # с символа '#' и до конца строки обозначаются комменты в лимбо
2.  
3. # переменные задаются так
4. # <var> : <type>;
5. # присваиваются так
6. # <var> = <data>;
7. # можно комбинировать
8. # <var> : <type> = <data>;
9. # так как все данные в лимбо имеют свой фиксированый тип
10. # и не делается никаких предположений и автокастингов, например
11. #   a : byte; b : int;
12. #   b = b + a; - выдаст ошибку
13. #   b = b + int a; будет правильно
14. # то существует и сокращенная запись создания переменной с одновременным ее присвоением.
15. # <var> := <data>;
16. # при этом, переменная <var> создается с типом как у <data> и ей инициализуется
17.  
18. implement T;  # обозначение начала кода модуля. в данном - модуля 'T'
19.  
20. # всякие инклуды описателей интерфейсов модулей. sys тут включен задля print, а одна из adt из draw нужна при декларации топ-функции в интерфейсе, который будет подхватывать шелл
21. include "sys.m";
22. sys : Sys;
23.  
24. include "draw.m";
25.  
26.  
27. # так задается интерфейс к модулю (тут 'T'). в нем записываются функции,
28. # данные (каналы в алефе/лимбо - просто типы данных), константы и структуры
29. # которые будут доступны везде
30. # интерфейсы, обычно, описываются в отдельных файлах (чуть выше инклудились .m это они)
31. #
32. # так как строгий тип имеет не только данные и функции, но и adt, и модуля,
33. # то именно такой формат интерфейса должен иметь модуль, чтобы он мог быть подхвачен sh
34. T: module {
35.   init : fn(ctxt: ref Draw->Context, vpar: list of string);
36. };
37.  
38.  
39. # в тут определена как заголовочная функция. почему - см выше и доки по лимбе
40. init(ctxt: ref Draw->Context, vpar: list of string){
41.   sys = load Sys Sys->PATH; # подгружаем модуль Sys.
42.  
43.   # создаем и заполняем массив из 10 каналов типа (32х целое, канал для строк)
44.   chns := array [10] of {* => chan of (int, chan of string)};
45.  
46.   # запускаем в отдельном потоке ф-цию foo, передав ей как параметр канал N 4 из массива выше.
47.   # вообщето тут надо было бы все 10 разбросать, но для простой демонстрации и одного достаточно.
48.   spawn foo(chns[4]);
49.  
50.   # ждем поступления данных по одному из каналов массива chns.
51.   # они придут в виде (N канала в массиве, пришедшие данные)
52.   (i, (v, rCh)) := <-chns;
53.  
54.   # выводим N канала и полученную цифру v.
55.   sys->print("i = %d, v = %d\n", i, v);
56.  
57.   # если был прислан канал rCh, посылаем по нему ответ
58.   # (тут стандартный лозунг "нало вод!" в сокращении)
59.   if(rCh != nil)
60.     rCh <-= "h w!";
61. }
62.  
63.  
64. foo(ch: chan of (int, chan of string)){
65.   rch := chan of string;   # cоздаем переменную и канал для строк к ней.
66.  
67.   если в параметрах был передан канал, посылаем по нему цифру 3 и канал для ответа
68.   if(ch != nil){
69.     ch <-= (3, rch);
70.    
71.     # ждем ответа, а когда он приходит - выводим его
72.     sys->print("%s\n", <-rch);
73.   }
74. }

прошу.

 

J0E
вот тут довольно неплохое довольно лаконичное описание некоторых особенностей limbo на русском. может, вам оно поможет.
http://powerman.name/Inferno/Limbo.html
более подробно в оф доках/буках

 

J0E

template<class InputIterator, class OutputIterator>

Код (Text):

1. OutputIterator copy ( InputIterator first, InputIterator last, OutputIterator result );

а что. если я захочу подставить вместо итераторов ввода итераторы вывода?

 

Откуда взялся полиморфизм? Кодогенерация.

jabocrack

Не корректное желание. Отличие в данном случае в семантике использования, а не в том что их нельзя менять местами.

 

Будет ошибка компиляции.

С такой точки зрения все объект, и целое число 0, но какое это имеет отношение к примеру? я не зря говорил про другой уровень абстракции.

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

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

По поводу примера. Даже с объяснениями я не понял зачем в нем потоки, они похоже не нужны с практической точки зрения (исключительно что бы показать что они есть в языке) поэтому я взял вольность упростить пример, реализовав потоки без асинхронности вычислений Еще были сложности понять зачем нужен номер потока и куда его прицепить, поэтому его убрал. К сожалению, в нем почти негде продемонстрировать фичи современных промышленных языков (использован F#).

Код (Text):

1. // функция потока, отправляет к канал число 3 и конвееризует его вывод в локальную функцию-приемник
2. let foo channel =
3.   let recv_ch s = printf "%s" s
4.   channel 3 |> recv_ch
5.  
6. // список из 10 каналов, 9 пустые.
7. let chns = [ None; None; None; None; Some(foo); None; None; None; None; None; None ]
8.  
9. // функция для коммуникации с каналом, выводит полученное от него число и передает ему привет.
10. let comm a = printf "%d" a; "Hello, World!"
11.  
12. // работает только с валидными каналами
13. let apply_some ch =
14.   match ch with
15.   | Some ch -> comm |> ch
16.   | None    -> ()
17.  
18. // прогоняем данные
19. List.iter apply_some chns

 

J0E

помойму все высказывания прекрасно соответствуют друг другу по логике
- и то, что целое число 0 == контейнер, включающий данные и код предназначенный для его рабты с данными этого контейнера,
- и то, что лимбо - язык отличающийся от С, по крайней мере в моем примере, только парой-тройкой фич, заимствованых из близкородственного паскаля-оберона, к тому же подробно прокомментированых, абсолютно не читабелен с точки зрения знатока С-потомков
- и в том, что хэловорд критикуется, почемуто, с точки зрения практической полезности.
- и то, что F# зачемто назван громкими словами - "промышленный язык". какой промышленности, не подскажете?

кто вы по профессии, если не секрет? те не на что учились, а чем занимаетесь/на булку с котлетой зарабатываете? что вы не программист-практик, это уже понятно.

насчет вашего "более лаконичного" примера на "легкочитаемом" и "с-подобном" F или как там его.

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

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

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

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

далее, вы создаете массив из 10тка функций, которые почемуто назвали каналами. инициализуете почемуто только одну (опять лаконизация?). кстати, а как бы вы поступили, если бы в массиве каналы бы использовалались для различных целей, в том числе и за пределами данного процесса заранее неопределенным обработчиком?
let chns = [ None; None; None; None; Some(foo); None; None; None; None; None; None ]

кстати, на лимбо строка выше могла бы выглядеть так
chns:= array [10] of { 4 => chan of <тип данных канала> };

let comm a = printf "%d" a; "Hello, World!"
я ведь тоже могу поубирать проверки на валидность и записать все в одну строку, тогда будет
sys->print("i = %d, v = %d\n", i, v); rCh <-= "h w!";

ну и очень распространенный момент слушанья пачки каналов
(i, (v, rCh)) := <-chns;

вы реализуете так
let apply_some ch =
match ch with
| Some ch -> comm |> ch
| None -> ()

List.iter apply_some chns

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

кстати, если вы смотрели ту шпаргалку, что я ссылил, то в лимбо (алеф, го) тоже есть альтерации по каналам.

 

qqwe

Верно, я и не говорю, что ты ошибаешься, дело в том, что мы мыслим на уровне разных абстракций, и я не могу объяснить разницу. Вот реализация на С++ почти 1:1 (но ты так и не объяснил зачем тредам номера, поэтому я опять чуть упростил задачу) и думаю она бельше похожа на С, разве что синтаксис шаблонов <> непривычен. Ну и что, банальный пример того, что в библиотеке, а не языке! можно реализовать практически все "фичи" Алефа пусть и более коряво выглядит.

Код (Text):

1. #include <array>
2. #include <thread>
3. #include <iostream>
4.  
5. using namespace std;
6.  
7. typedef pair<int, promise<string>*> response;
8. typedef promise<response> request;
9.  
10. void foo(request* ch){
11.   //rch := chan of string;   # cоздаем переменную и канал для строк к ней.
12.   promise<string> rch;
13.  
14.   unique_future<string> frch = rch.get_future();
15.  
16.   //если в параметрах был передан канал, посылаем по нему цифру 3 и канал для ответа
17.   //if(ch != nil){
18.   //  ch <-= (3, rch);
19.   if ( ch ) {
20.     ch->set_value(response(3, &rch));
21.    
22.     //  # ждем ответа, а когда он приходит - выводим его
23.     //  sys->print("%s\n", <-rch);
24.     cout << frch.get() << endl;
25.   }
26. }
27.  
28. int main()
29. {
30.   // # создаем и заполняем массив из 10 каналов типа (32х целое, канал для строк)
31.   // chns := array [10] of {* => chan of (int, chan of string)};
32.   typedef request channel;
33.   array<channel, 10> chns;
34.   channel* ch4 = &chns[4];
35.  
36.   unique_future<response> frch = ch4->get_future();
37.  
38.   // # запускаем в отдельном потоке ф-цию foo, передав ей как параметр канал N 4 из массива выше.
39.   // # вообщето тут надо было бы все 10 разбросать, но для простой демонстрации и одного достаточно.
40.   // spawn foo(chns[4]);
41.   thread spawned(foo, ch4);
42.  
43.   // # ждем поступления данных по одному из каналов массива chns.
44.   // # они придут в виде (N канала в массиве, пришедшие данные)
45.   // (i, (v, rCh)) := <-chns;
46.   response rch( frch.get() );
47.  
48.   // # выводим N канала и полученную цифру v.
49.   // sys->print("i = %d, v = %d\n", i, v);
50.   cout << "i = 4, v = " << rch.first << endl;
51.  
52.   // # если был прислан канал rCh, посылаем по нему ответ
53.   // # (тут стандартный лозунг "нало вод!" в сокращении)
54.   //if(rCh != nil)
55.   //  rCh <-= "h w!";
56.   if ( rch.second )
57.     rch.second->set_value("h w!");
58.  
59.   spawned.join();
60. }

Пример на F# я привел что бы показать какие зазачи можно решать на уровне синтаксиса. Надеюсь, обратил внимание на запятые?

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

Каналы, реализованные в виде функций, полиморфны. "Проверка на валидность каналов" происходит в apply_some, None это кстати не "не инициализировано" а пустой тип. И не надо утверждать, что програма "не такая" - побочный эффект идентичен, за исключением оговоренного упрощения. Однако большинство работы выполнено во время компиляции.

> если бы вы не читили, а реализовали на вашем Ф предложенный пример в полной мере

Зачем? Я решаю обычно только практические задачи И поэтому кстати и сомневаюсь в Алефе. Ну, крутой может язык, и что это даст? да их вагон и маленькая тележка таких. Однако опыта использования у меня нет, поэтому приходится смотреть на чужой, и тут как раз выигрывают "промышленные" языки, то есть на которых уже написано приличное количество кода, выяснены проблемы, думаете Страуструп видел те вопросы что стоят сейчас в Коммитете? Как бы ни так, только благодоря годам использования они прояснились, то же касается .Net и ML (на котором написано прилично кода в Xen Server).

 

Продолжим )

А мне понятно, что ты огорчился увидев "из-за поверхностного знакомства с альтернативами" и теперь места себе не находишь, не определив меня Это обычно: когда нет аргументов, переходят на линости. Но обрати внимание на разницу: я говорил не о тебе лично, а об оставленном тобой мнении, которое расходится и с мнением Степанова:

и вообще слово "объект" в его "руководстве по STL" употребляется везде в контексте "функциональный", почитай.

Мое мнение не совсем голословно, а подтверждено примерами А вот на основании чего ты делаешь свои выводы, остается только догадываться, можешь озвучить предпосылки? Потому что я как раз учился по 2205, а зарабатываю разработкой софта, хотя ты в чем-то прав, кодинга может 5% от общего времени, большей частью ресерч и рефакторинг чужого кода (в том числе и не предназначенного для чтения). И еще я из тех теоретиков, кто иногда говорит: "нет, за пару дней закодить это не получится, будем изучать технологию Х" и это оказывается оправданно. Но не всегда сбывается оптимистичные прогнозы, вроде текущего: "тратить время на углубленное изучение Алеф нет смысла, язык не дает особых преимуществ перед С++, имеет сложный компилятор с потенциальными ошибками". Вот и опасаюсь как бы не пришлось поменять свое мнение позже)