Oberon space
General Category => Общий раздел => Тема начата: valexey_u от Апрель 03, 2013, 08:39:30 pm
-
Я же уже упоминал что на Rust мозилловцы экспериментальный браузеродвижок пишут (весь такой асинхронно-параллельный)? Вот этот: https://github.com/mozilla/servo (иначе нафига мозилле этот руст вообще?)
Так вот, недавно оно вышло на новый уровень - мозилла заключила с самсунгом договор о сотрудничестве в плане развития этого движка. Так что теперь похоже стоит ожидать скорейшей стабилизации руста как языка, и допила этого самого движка до состояния вменяния. Самсунг явно старается освободиться от гуглозависимости (то есть от андроида и вебкита).
Первые плоды сотрудничества - свежий релиз Rust 0.6 в котором самсунг по быстрому реализовал поддержку ARM-архитектуры (оно и понятно, Самсунг заинтересован браузер на базе этого движка воткнуть на смартфоны).
Подробнее новость тут: http://www.opennet.ru/opennews/art.shtml?num=36576
И тут: https://blog.mozilla.org/blog/2013/04/03/mozilla-and-samsung-collaborate-on-next-generation-web-browser-engine/
Так что с некой вероятностью, вскоре монополия С++ на браузерные движки может закончиться :-)
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
Кстати, ADT без паттерн-матчинга ведь нафиг не нужны. Посему вопрос - что там у руста с паттерн-матчингом?
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
Кстати, ADT без паттерн-матчинга ведь нафиг не нужны. Посему вопрос - что там у руста с паттерн-матчингом?
Да, вижу, там все норм с паттерн-матчингом:
fn area(sh: Shape) -> float {
match sh {
Circle(_, size) => float::consts::pi * size * size,
Rectangle(Point { x, y }, Point { x: x2, y: y2 }) => (x2 - x) * (y2 - y)
}
}
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
Симитировать-то можно, а использовать так как надо (что бы от них реальный толк был) -- нельзя. Как и в шарпе, паскалях...
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
Симитировать-то можно, а использовать так как надо (что бы от них реальный толк был) -- нельзя. Как и в шарпе, паскалях...
Почему же нельзя? Очень даже можно. Получается ATD+pattern matching. Без написания тонн кода руками.
-
В этом Расте, что интересно, есть АлгТД (замаскированные под перечисления), были бы ещё классы типов -- вообще зачётный язык вышел бы...
Да фигня эти ADT, вон в плюсах их тоже можно сделать :-) Был бы язык высокоуровневый, а ADT приложатся ;-)
Кстати, ADT без паттерн-матчинга ведь нафиг не нужны. Посему вопрос - что там у руста с паттерн-матчингом?
Да, вижу, там все норм с паттерн-матчингом:
fn area(sh: Shape) -> float {
match sh {
Circle(_, size) => float::consts::pi * size * size,
Rectangle(Point { x, y }, Point { x: x2, y: y2 }) => (x2 - x) * (y2 - y)
}
}
Да, вот ещё примерчик:
enum List<X> { Nil, Cons(X, @List<X>) }
let x: List<int> = Cons(10, @Cons(11, @Nil));
match x {
Cons(a, @Cons(b, _)) => {
process_pair(a,b);
}
Cons(10, _) => {
process_ten();
}
Nil => {
return;
}
_ => {
fail!();
}
}
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
-
Симитировать-то можно, а использовать так как надо (что бы от них реальный толк был) -- нельзя. Как и в шарпе, паскалях...
Почему же нельзя? Очень даже можно. Получается ATD+pattern matching. Без написания тонн кода руками.
Приведи пример на плюсах, возможно я смогу объяснить на нём, что именно мне не нравится в такой имитации.
По-крайней мере, в сишарпе мне не удалось симитировать те же хаскельные типы Maybe и Either так, что бы это было действительно полезно -- в плане повышения надёжности софта. Только многословия добавил в результате. Язык (C#) -- ацтойный...
-
Чтобы не быть голословным, вот на плюсах ADT + pattern matching:
typedef boost::variant<boost::blank, int, string, vector<int>> var_t;
vector<int> vit;
var_t myFooV = vit;
auto visitor = make_lambda_visitor<void>(
[](int v) -> void { cout << "int: " << v << endl; },
[](string& v) -> void{ cout << "string: " << v << endl; },
[](vector<int>& v) -> void{
v.push_back(27);
boost::get<vector<int>>(myFooV).push_back(34);
cout << " vector.. has elements: " << v.size() << endl;
}
);
boost::apply_visitor( visitor , myFooV );
Не сказал бы что мне вот прям идеально нравится эта реализация, по моему мнению можно сделать ещё краше. Но тем не менее :-)
-
Чтобы не быть голословным, вот на плюсах ADT + pattern matching:
typedef boost::variant<boost::blank, int, string, vector<int>> var_t;
vector<int> vit;
var_t myFooV = vit;
auto visitor = make_lambda_visitor<void>(
[](int v) -> void { cout << "int: " << v << endl; },
[](string& v) -> void{ cout << "string: " << v << endl; },
[](vector<int>& v) -> void{
v.push_back(27);
boost::get<vector<int>>(myFooV).push_back(34);
cout << " vector.. has elements: " << v.size() << endl;
}
);
boost::apply_visitor( visitor , myFooV );
Не сказал бы что мне вот прям идеально нравится эта реализация, по моему мнению можно сделать ещё краше. Но тем не менее :-)
Мамин ёжик, жесть-то какая.
Идею вроде понял, но -- у этих псевдо-АлгТД даже имени конструктора (варианта) нет. Не то, совсем не то...
Ну вот попробуй симитировать Maybe и Either... Ну или List, хотя бы...
-
Кусок из https://github.com/mozilla/servo/blob/master/src/servo/html/cssparse.rs
/// Where a style sheet comes from.
pub enum StylesheetProvenance {
UrlProvenance(Url),
InlineProvenance(Url, ~str),
}
pub fn spawn_css_parser(provenance: StylesheetProvenance,
resource_task: ResourceTask)
-> Port<Stylesheet> {
let (result_port, result_chan) = comm::stream();
let provenance_cell = Cell(provenance);
do task::spawn {
let url = do provenance_cell.with_ref |p| {
match *p {
UrlProvenance(copy the_url) => the_url,
InlineProvenance(copy the_url, _) => the_url
}
};
let sheet = Stylesheet::new(url, data_stream(provenance_cell.take(),
resource_task.clone()));
result_chan.send(sheet);
}
return result_port;
}Так-то в принципе весьма неплохо, но всё же эти {} и ваще синтаксический мусор...
Но по сравнению с тем, что тут выше на с++ boost variant было показано -- просто прелесть...
-
Чтобы не быть голословным, вот на плюсах ADT + pattern matching:
typedef boost::variant<boost::blank, int, string, vector<int>> var_t;
vector<int> vit;
var_t myFooV = vit;
auto visitor = make_lambda_visitor<void>(
[](int v) -> void { cout << "int: " << v << endl; },
[](string& v) -> void{ cout << "string: " << v << endl; },
[](vector<int>& v) -> void{
v.push_back(27);
boost::get<vector<int>>(myFooV).push_back(34);
cout << " vector.. has elements: " << v.size() << endl;
}
);
boost::apply_visitor( visitor , myFooV );
Не сказал бы что мне вот прям идеально нравится эта реализация, по моему мнению можно сделать ещё краше. Но тем не менее :-)
Мамин ёжик, жесть-то какая.
Идею вроде понял, но -- у этих псевдо-АлгТД даже имени конструктора (варианта) нет. Не то, совсем не то...
Ну вот попробуй симитировать Maybe и Either... Ну или List, хотя бы...
Имена, как понимаешь, ты можешь дать самостоятельно обозвав каждый из вариантов в варианте по своему (свой тип). Да, а жести ты пока не видел - жесть она в реализации :-)
List делать через ADT в плюсах, очевидно не нужно, просто потому, что там есть другой механизм для создания подобных структур (это в хаскеле другого механизма просто нет).
Ну а Maybe тут сделать можно, но зачем Maybe без монад? Без монад оно не юзабельно же.
-
Так-то в принципе весьма неплохо, но всё же эти {} и ваще синтаксический мусор...
Но по сравнению с тем, что тут выше на с++ boost variant было показано -- просто прелесть...
Посмотрел код - это полная жесть! Для того, чтобы понять что экспортирует этот модуль, нужно прочесть ВСЮ реализацию!
PS. А у тебя придирки на уровне синтаксиса - это не серьезно.
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
-
Ну а Maybe тут сделать можно, но зачем Maybe без монад? Без монад оно не юзабельно же.
Maybe даже без монад полезен -- для предотвращения ошибок с null-pointer'ами
-
Так-то в принципе весьма неплохо, но всё же эти {} и ваще синтаксический мусор...
Но по сравнению с тем, что тут выше на с++ boost variant было показано -- просто прелесть...
Посмотрел код - это полная жесть! Для того, чтобы понять что экспортирует этот модуль, нужно прочесть ВСЮ реализацию!
PS. А у тебя придирки на уровне синтаксиса - это не серьезно.
Ну, я, видимо, привык к этому после всяких сишарпов да хаскеллей (да-да, многие хаскеллеры не утруждают себя составлением списка экспорта и экспортирую прямо всё что есть в модуле)...
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Да даже если и не будут, один фиг можно :-) Синтаксис как синтаксис. Мало отличается от той же Ады и прочих Xаскелей.
-
и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Привыкнуть можно даже к лисповскому синтаксису, но если уж делают язык с современной семантикой, могли бы уж и современный синтаксис прикрутить...
-
Ну а Maybe тут сделать можно, но зачем Maybe без монад? Без монад оно не юзабельно же.
Maybe даже без монад полезен -- для предотвращения ошибок с null-pointer'ами
И как его потом разруливать? Через case?
Не, в таком виде Maybe я в плюсах конечно видел. Тоже мне, проблема. Ну, см. тот же boost::option например. Да и на варианте это делается с полпинка. Но это ж не удобно, так вот без монад юзать Maybe. Это ж после каждой функции нужно втыкать ветвление (через case) для обоих вариантов развития событий. Код превращается в черт знает что.
-
и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Привыкнуть можно даже к лисповскому синтаксису, но если уж делают язык с современной семантикой, могли бы уж и современный синтаксис прикрутить...
А что такое современный синтаксис? Питон не предлагать - жестко прибитые гвоздями отступы нинужны.
И я правильно понимаю, что тебя волнуют и беспокоят только фигурные скобочки? :-)
-
Да, а у лиспа нет синтаксиса :-) В этом его проблема и в этом его сила.
-
Так-то в принципе весьма неплохо, но всё же эти {} и ваще синтаксический мусор...
Но по сравнению с тем, что тут выше на с++ boost variant было показано -- просто прелесть...
Посмотрел код - это полная жесть! Для того, чтобы понять что экспортирует этот модуль, нужно прочесть ВСЮ реализацию!
PS. А у тебя придирки на уровне синтаксиса - это не серьезно.
Ну, я, видимо, привык к этому после всяких сишарпов да хаскеллей (да-да, многие хаскеллеры не утруждают себя составлением списка экспорта и экспортирую прямо всё что есть в модуле)...
Дык говно же получается. Вот беру я новую стороннюю либу (или свою которую писал когда-то раньше) и хз как её использовать - модуль есть, а спеки на него нет. В качестве костыля можно конечно использовать сгенереную доку в браузереи автокомплит в IDE - но это кривые и не удобные костыли.
Когда я пользую некий модуль, то мне удобно слева открыть свой пишущийся код, а справа, в этом же текстовом редакторе каким бы он ни был, открыть спеку на модуль (спеку нормально руками писанную, с комментами). Ну и вообще знакомиться с чужой либой по её модульным спекам (предварительно прочтя высокоуровневую доку в браузере) много приятнее и быстрее чем прыгая из кода в браузер и обратно, или прыгая по автокомплитам. Это получается быстрее просто потому, что меньше переключений контекстов. Работаешь в однородной среде, причем можешь видеть описалово сразу нескольких связанных сущностей.
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Да даже если и не будут, один фиг можно :-) Синтаксис как синтаксис. Мало отличается от той же Ады и прочих Xаскелей.
ммм. скажем так... предположим , что стоит задача отображения некоторого алгоритма в ЯВУ... по субьективным оценке степень концентрации, которую ДОЛЖЕН иметь программер для раста не намного меньше чем требуемая для с++ (если вообще меньше).. но больше чем для Go. Поэтому, напрягаться не имея сурьезных оснований ,имхо, не резон.. Наверное по этому я так и не могу заставить себя написать что либо на Хацкеле... ибо через 5 -10 минут возникает вопрос..- нафига козе боян..?
-
Между прочим, по моим наблюдениям я (возможно кто-то иначе) лучше всего разбираюсь в не известном стороннем коде на двух языках - на Аде и на Модуле-3 (это из опыта). Затем идет, скажем так, обычный хорошо оформелнный C++.
Под разобраться я подразумеваю понять что где находится, для чего предназначено и как это использовать. Не вдаваясь в реализацию без крайней на то необходимости. То есть как пользователь этой либы, а не как контрибьютер.
А на другом полюсе, то есть хуже всего, не приятней всего мне разбираться с кодом stl, boost, Oberon/CP (справедливости ради я беру сейчас только языки-потомки Алгола, то есть из общей группы, имеющие общего предка).
Общее у тех кто в топе пожалуй одно - у них нормально разделена реализация и спецификация модуля, причем спецификация на модуль пишется руками а не генерируется тулзой.
На дне у нас языки и либы в которых реализация и спецификация круто перемешаны в одном файле. Где-то в придонных водах болтаются также C#, Java, D, Go. Первые два на дно не попали просто потому, что их как-то вытягивает крутые IDE. D же "спасает" то, что либ там мало, они пишутся довольно таки высококласными программистами с любовью (а не тупо потому что бабла отвалили), ну и сам язык побогаче той же жабы. Go - "спасает" вменяемая IDE, вменяемые доки, тулзы и опять таки отсутствие тонн говнокода.
Но никакая IDE не дает такого понимания кода какое наличие вменяемой модульности в языках. Такой модульности как в Модуле-3 и Аде.
Я через несколько часов знакомства с Модулой-3 начал нормально ориентироваться в либах и нашел то, что мне было нужно. Причем нашел и запомнил, оно в моск въелось в так, что я до сих пор помню что там и как в плане использования. А чтобы начать ориентироваться в исходниках оберона мне пришлось прочитать книжку Вирта (ну да, эта такая hand made спека по стандартным модулям и либам). Просто взять и начать разбираться в сторонней либе Обероновской очень не просто (если она не тривиальна).
-
А что такое современный синтаксис? Питон не предлагать - жестко прибитые гвоздями отступы нинужны.
Ну а вот мне нужны -- заставляют всех программистов на этом языке писать более-менее единообразный аккуратный код. Хотя в таком синтаксисе не всё нормально выравнивается, так что есть ещё куда ужесточать правила синтаксического оформления...
И я правильно понимаю, что тебя волнуют и беспокоят только фигурные скобочки? :-)
В основном да, остальное более-менее приемлемо.
Ну, конечно же, ещё нужно нормальное оформление секций экспорта -- не так, как хедеры в сях или недоэкспорт в хаскелле, а наподобии модулы-2 и ады...
-
Maybe даже без монад полезен -- для предотвращения ошибок с null-pointer'ами
И как его потом разруливать? Через case?
Не, в таком виде Maybe я в плюсах конечно видел. Тоже мне, проблема. Ну, см. тот же boost::option например. Да и на варианте это делается с полпинка. Но это ж не удобно, так вот без монад юзать Maybe. Это ж после каждой функции нужно втыкать ветвление (через case) для обоих вариантов развития событий. Код превращается в черт знает что.
В большинстве случаев такое разветвление всё равно необходимо -- хотя бы для того что бы залогировать ошибки. Пропускать это всё конвейером через монаду maybe не всегда возможно.
Вот именно что в с++/с# нет нормального паттерн-матчинга и попытка матчинга через лес if-ов даёт неприемлемый по внешнему виду код, который к тому же не даёт самой главной фишки АлгТД -- инкапсуляции данных, содержащихся внутри разных вариантов (конструкторов АлгТД).
Возникает необходимость объявлять глобальные переменные, не имеющие смысла в обработчиках других вариантов, но тем не менее доступных в них.
Таким путём не справиться с проблемой нулевых указателей и т. п., что очень хорошо решается с помощью настоящих АлгТД...
-
Но никакая IDE не дает такого понимания кода какое наличие вменяемой модульности в языках. Такой модульности как в Модуле-3 и Аде.
Я через несколько часов знакомства с Модулой-3 начал нормально ориентироваться в либах и нашел то, что мне было нужно. Причем нашел и запомнил, оно в моск въелось в так, что я до сих пор помню что там и как в плане использования. А чтобы начать ориентироваться в исходниках оберона мне пришлось прочитать книжку Вирта (ну да, эта такая hand made спека по стандартным модулям и либам). Просто взять и начать разбираться в сторонней либе Обероновской очень не просто (если она не тривиальна).
Модулу-3 я не знаю, как я понял, она несильно отличается в плане definition module от Модулы-2, так что в целом согласен...
-
Но никакая IDE не дает такого понимания кода какое наличие вменяемой модульности в языках. Такой модульности как в Модуле-3 и Аде.
Я через несколько часов знакомства с Модулой-3 начал нормально ориентироваться в либах и нашел то, что мне было нужно. Причем нашел и запомнил, оно в моск въелось в так, что я до сих пор помню что там и как в плане использования. А чтобы начать ориентироваться в исходниках оберона мне пришлось прочитать книжку Вирта (ну да, эта такая hand made спека по стандартным модулям и либам). Просто взять и начать разбираться в сторонней либе Обероновской очень не просто (если она не тривиальна).
Модулу-3 я не знаю, как я понял, она несильно отличается в плане definition module от Модулы-2, так что в целом согласен...
А Модулу-2 не знаю я :-) Я её видел только в Эксельсиоре, да там был диалектъ с printf'ами да переменным числом аргументов у функции.
-
Maybe даже без монад полезен -- для предотвращения ошибок с null-pointer'ами
И как его потом разруливать? Через case?
Не, в таком виде Maybe я в плюсах конечно видел. Тоже мне, проблема. Ну, см. тот же boost::option например. Да и на варианте это делается с полпинка. Но это ж не удобно, так вот без монад юзать Maybe. Это ж после каждой функции нужно втыкать ветвление (через case) для обоих вариантов развития событий. Код превращается в черт знает что.
В большинстве случаев такое разветвление всё равно необходимо -- хотя бы для того что бы залогировать ошибки. Пропускать это всё конвейером через монаду maybe не всегда возможно.
Там обычно идут однотипные действия вроде того - написать в лог то что случилось, и выйти. Ну, то есть это вполне в монаду заворачивается.
Вот именно что в с++/с# нет нормального паттерн-матчинга и попытка матчинга через лес if-ов даёт неприемлемый по внешнему виду код, который к тому же не даёт самой главной фишки АлгТД -- инкапсуляции данных, содержащихся внутри разных вариантов (конструкторов АлгТД).
Возникает необходимость объявлять глобальные переменные, не имеющие смысла в обработчиках других вариантов, но тем не менее доступных в них.
Таким путём не справиться с проблемой нулевых указателей и т. п., что очень хорошо решается с помощью настоящих АлгТД...
Эээ.. Чаво? Где в моем примере с ADT&pattern-matching глобальные переменные и прочее разное о чем ты написал? Все там ок, с точки зрения ADT да паттерно-матчинга. А если это дело еще и макросами засахарить, то и синтаксической избыточности не будет :-) Но я не люблю сахар.
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Да даже если и не будут, один фиг можно :-) Синтаксис как синтаксис. Мало отличается от той же Ады и прочих Xаскелей.
ммм. скажем так... предположим , что стоит задача отображения некоторого алгоритма в ЯВУ... по субьективным оценке степень концентрации, которую ДОЛЖЕН иметь программер для раста не намного меньше чем требуемая для с++ (если вообще меньше).. но больше чем для Go. Поэтому, напрягаться не имея сурьезных оснований ,имхо, не резон.. Наверное по этому я так и не могу заставить себя написать что либо на Хацкеле... ибо через 5 -10 минут возникает вопрос..- нафига козе боян..?
В случае отображении некого алгоритма на ЯВУ, будет удобней быстрее и безошибочней писать на том, на чем ты привык, где рука набита. Если рука набита на плюсах, то на плюсах и реализуешь быстрее и качественнее чем на Go или Rust'e.
А если говорить не про некий алгоритм, а про разработку промышленного ПО, то концентрация этого самого внимания в Go требуется огого-какое. Хотя бы просто потому, что там приходится лепить велосипеды на ровном месте, там, где в С++ все решается в одну строчку. И ладно бы просто велосипеды, но приходится лепить ОДИН И ТОТ ЖЕ ВЕЛОСИПЕД много-много раз, либо по сути лепить динамическую типизацию, а чтобы не было в рантайме ошибок опять повышать концентрацию внимания. ЗАДОЛБАЛО!
В этом плане Rust и C++ лучше. На много лучше. Концентрироваться вниманием можно меньше.
PS. Но при чем тут собственно синтаксис? Проблемы в Go не из за него. Да и головоломки в хаскеле тоже не из за него.
-
А Модулу-2 не знаю я :-) Я её видел только в Эксельсиоре, да там был диалектъ с printf'ами да переменным числом аргументов у функции.
Ну как же, Turbo/JPI/TopSpeed Modula-2 -- из-за этого компилятора группа ведущих компиляторщиков ушла из Борланда, из-за того что Борланд не хотел пилить сук турбо паскалю.
У меня есть какая-то бумажная книга по модуле-2, и я на этом компиляторе даже какие-то проги как-то делал. Маленькие прожки, ничего серьёзного, в 90-х...
-
У меня есть какая-то бумажная книга по модуле-2...
Кажись вот эта:
(http://mirknig.com/uploads/posts/2011-03/1298969704_1.png) (http://mirknig.com/knigi/programming/1181379840-programmirovanie-na-yazyke-modula-2.html)
Точно не помню, давно не листал её ))
-
Эээ.. Чаво? Где в моем примере с ADT&pattern-matching глобальные переменные и прочее разное о чем ты написал? Все там ок, с точки зрения ADT да паттерно-матчинга. А если это дело еще и макросами засахарить, то и синтаксической избыточности не будет :-) Но я не люблю сахар.
Ну, твой пример на лямбдах мало того что синтаксически грязный, так ещё и недоделанный -- нет имён конструкторов (вариантов).
А если смотреть примеры использования boost::optional, то он какой-то не такой как Maybe в хаскелле или option в окамлях.
Эьт глобальные переменные вылезли у меня на сишарпе, но я тогда не додумался использовать лямбды для имитации паттерн-матчинга. Надо подумать, может что-то толковое выйдет...
-
Проблемы в Go не из за него.
А из-за чего проблемы в Go? Ну, кроме отсутствия нормальных спецификаций модулей (как в аде)?
-
Проблемы в Go не из за него.
А из-за чего проблемы в Go? Ну, кроме отсутствия нормальных спецификаций модулей (как в аде)?
Из за отсутствия обобщенки в каком-либо виде. В результате нет ни обобщенных алгоритмов в стандартной либе, ни вменяемых контейнеров. То что есть - то чисто на динамической типизации работает (клади в них что хочешь). Если хочется статической типизации - надо велосипедить свое под данный конкретный тип (а потом копипастить его для каждого нового типа). Это просто жесть. Этим настолько не удобно пользоваться, то я подумываю если не о миграции приложения целиком на другой язык, то по крайней мере о выносе основной логики.
-
Ну, короче, как я сразу и понял, когда этот гугл Go только появился, -- фтопку его )))
-
В случае отображении некого алгоритма на ЯВУ, будет удобней быстрее и безошибочней писать на том, на чем ты привык, где рука набита. Если рука набита на плюсах, то на плюсах и реализуешь быстрее и качественнее чем на Go или Rust'e.
С этим заключением согласен, но я имел ввиду "одинаковую набитость"(точка зрения новичка знакомого с алгоритмизацией, понимающим отображаемый алгоритм, но не имеющего "набитой руки" в ЯВУ), для всех рассматриваемых языков, и мнение мое чисто субьективное. Наверное, аккуратнее было бы для этой характеристики использовать термин "порог вхождения"...
-
и, разумеется, отображаемый алгоритм берется из некоторой общей (для всех рассматриваемых ЯВУ) области эффективного использования.
-
Алексей, какие контейнеры вам чаще всего необходимы? Не обдумывали ли Вы вариант написания модуля с макроименами идентификаторов и использования небольшого скрипта для генерации конкретных модулей. Скажем, из файла Vector с параметром (String) в VectorString. Я размышляю над возможностью обобщённого программирования в Обероне. Не ясно, может ли такая ручная генерация заменить привычное для С++ мета-программирование.
-
Алексей, какие контейнеры вам чаще всего необходимы?
map, set, multi_map, multi_set, queue, unordered_set (аналоги vector, unordered_map в Go есть - оно тупо вшито в язык). Ну а также возможности свои обобщенные контейнеры лепить типа ring buffer'a.
Не обдумывали ли Вы вариант написания модуля с макроименами идентификаторов и использования небольшого скрипта для генерации конкретных модулей. Скажем, из файла Vector с параметром (String) в VectorString. Я размышляю над возможностью обобщённого программирования в Обероне. Не ясно, может ли такая ручная генерация заменить привычное для С++ мета-программирование.
Это будет хуже, чем попытка обобщенки на Сишных макросах (до Си11). Так что нет, не думал.
А Обобщенку в Обероне если и делать, то в стиле Модулы-3.
-
А как она реализована в Модуле 3? Что-то я по беглому просмотру сообщения о языке не нахожу ничего.
-
А как она реализована в Модуле 3? Что-то я по беглому просмотру сообщения о языке не нахожу ничего.
http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_5_5Generics.html
-
Но во всех этих новомодных языках есть одна единая беда - там те же проблемы с модульностью, что и в Обероне - эта модульность не для людей.
В Расте ещё и синтаксис отстойный -- все эти фигурные скобочки бесят уже...
такой же уродливо- невзрачный , как и в СИ с плюсами.. но привыкнуть можно... если деньги платить будут.. :) где -то за пару недель.. по субьективным ощущениям...
Я для паскаля использую программу sed, сначала исходник пропускаю через неё, потом компилю. Костыль, конечно.
s/THEN/then begin/g
s/ELSIF/end; else if/g
s/ELSE/end; else begin/g
Для си подобных, сложнее особенно если регистр зафиксирован.
s/IF/if/g
s/THEN/{/g
s/ELSIF/} else if/g
s/ELSE} else {/g
Для си я всё сделал на макросах в отдельном .h файле. Если нужен такой синтаксис просто подключаю к конкретному .c файлу.
-
А возможно ли написать компилятор безопасного и совместимого диалекта C++? Оберун с синтаксисом C++. Тогда не нужно создавать новые языки. Типа C-- C minus minus :)
-
А возможно ли написать компилятор безопасного и совместимого диалекта C++? Оберун с синтаксисом C++. Тогда не нужно создавать новые языки. Типа C-- C minus minus :)
Типа такого уже было, Cyclone (http://en.wikipedia.org/wiki/Cyclone_(programming_language)), например
-
Поискал о нём информацию, информации по приминению мало. Есть патчи для gcc на их сайте, всё в исходниках, собранного компилятора для windows нет.
-
Сравнение D и Rust
http://versusit.ru/rust-vs-d
Посмотрим теперь, как будет выглядеть код, выводящий числа от 0 до 10. На Rust это будет так:
fn main() {
for 100.times {
io::println("Hello");
}
}
На D аналогичный код бы выглядел следующим образом:
void main() {
for (int i = 0; i < 10; i++) {
writeln("Hello");
}
}
for 100.times {
io::println("Hello");
}
Выводит Hello 10 раз, но из написанного это непонятно. Откуда взялось 100 и time?
-
Поискал о нём информацию, информации по приминению мало. Есть патчи для gcc на их сайте, всё в исходниках, собранного компилятора для windows нет.
Вот ещё проект -- россиянина какого-то: http://home.perm.ru/strannik/
Компилятор, поддерживающий три синтаксиса для одного по сути языка -- сишный, оберонский и паскалевский. Там есть компилятор для винды с примерами в том числе GUI-программ...
-
for 100.times {
io::println("Hello");
}
Выводит Hello 10 раз, но из написанного это непонятно. Откуда взялось 100 и time?
Подозреваю, что тут ошибка и должно было быть 10.times.
As a Rubyist, you probably don't know anything about that, so let's talk code first, and get into what exactly all that means later. Here's some code that prints "Hello" 100 times:
fn main() {
for 100.times {
io::println("Hello");
}
}
You may remember this from earlier. This loops 100 times, printing "Hello."
-
Понятно, укороченный for, меня сбило слово time - время.
-
Раз уж речь зашла о синаксисе хотел спросить, для чего в pascal Вирт использовал операторы
if then begin
end
else begin
end
В следующем языке modula 1 операторы записывались if then else end, почему в паскале сразу не реализовали?
-
В паскале можно написать:
if a < b then print(a);
Наверно казалось, что так проще. А в c/c++ до сих пор так ;)
-
Понятно, укороченный for, меня сбило слово time - время.
Не понял, где там слово time (время)? Там есть слово times (раз). "100.times" по-видимому означает "100 раз".
Видимо, целые числа являются в Расте объектами и имеют метод (или свойство) times. Документация на их сайте не очень...
-
Раз уж речь зашла о синаксисе хотел спросить, для чего в pascal Вирт использовал операторы
if then begin
end
else begin
end
В следующем языке modula 1 операторы записывались if then else end, почему в паскале сразу не реализовали?
Это пошло ещё с алгола -- паскаль ведь был виртовским взглядом на развитие алгола и ответом на алгол-68, который Вирту показался переусложнённым.
-
Сравнение D и Rust
http://versusit.ru/rust-vs-d
Посмотрим теперь, как будет выглядеть код, выводящий числа от 0 до 10. На Rust это будет так:
fn main() {
for 100.times {
io::println("Hello");
}
}
На D аналогичный код бы выглядел следующим образом:
void main() {
for (int i = 0; i < 10; i++) {
writeln("Hello");
}
}
Ни тот ни другой код ЧИСЛА не выводит. Какая-то феерическая чушь написана.
На D вообще тоже через range вывести можно, то есть указав диапазон а не воткнув явным образом переменную цикла.
В общем, пусть аффтар выпьет йаду.
-
Атака на оптимизацию хвостовой рекурсии растовцам не удалась:
[rust-dev] Tail call optimization (https://mail.mozilla.org/pipermail/rust-dev/2013-April/003557.html)
On 10/04/2013 5:43 AM, Artella Coding wrote:
> Hi does rust do tail call optimization? The reason I am asking is that
> the following tail call recursive implementation results in a stack
> overflow. Thanks.
No, and it very likely won't. We have a longstanding bug on this:
https://github.com/mozilla/rust/issues/217
as well as a wiki page and several mailing list threads:
https://github.com/mozilla/rust/wiki/Bikeshed-tailcall
https://mail.mozilla.org/pipermail/rust-dev/2011-August/000689.html
https://mail.mozilla.org/pipermail/rust-dev/2012-January/001280.html
...
The summary of all this is:
- We all know that tail calls are a virtuous language feature.
Further elaboration of their virtues is not required. Many of us
have lisp and ML backgrounds and would quite like them. Their
absence is heartache and sadness, not arrived-at lightly.
- Tail calls "play badly" with deterministic destruction. Including
deterministic drop of ~ boxes. Not to say that they're not
composable, but the options for composing them are UI-awkward,
performance-penalizing, semantics-complicating or all of the above.
- Tail calls also "play badly" with assumptions in C tools, including
platform ABIs and dynamic linking.
- Tail calls require a calling convention that is a performance hit
relative to the C convention.
- We find most cases of tail _recursion_ convert reasonably well to
loops, and most cases of non-recursive tail calls encode state
machines that convert reasonably well to loops wrapped around
enums. Neither of these are _quite_ as pretty as the
tail-call-using variants, but they do work and are "as fast"*,
as well as idiomatic for C and C++ programmers (who are our
primary audience).
I'm sorry to be saying all this, and it is with a heavy heart, but we
tried and did not find a way to make the tradeoffs associated with them
sum up to an argument for inclusion in rust.
-Graydon
* speed-wise, a switch-in-a-loop state machine is indirect dispatch so
will likely run slower than a state machine encoded by tail calls from
state to state; on the other hand if the way to get this performance
"back" is to turn on tail calls everywhere, we'd be trading one isolated
suboptimal-perf case for a cross-all-programs suboptimal-perf tax. We
don't find this trade acceptable.
Ну что за ниосиляторы такие...
via http://thesz.livejournal.com/1368099.html
-
for 100.times {
io::println("Hello");
}
Выводит Hello 10 раз, но из написанного это непонятно. Откуда взялось 100 и time?
Подозреваю, что тут ошибка и должно было быть 10.times.
As a Rubyist, you probably don't know anything about that, so let's talk code first, and get into what exactly all that means later. Here's some code that prints "Hello" 100 times:
fn main() {
for 100.times {
io::println("Hello");
}
}
You may remember this from earlier. This loops 100 times, printing "Hello."
Нет здесь никакой ошибки... ибо четко сказано "Here's some code that prints "Hello" 100 times:"... time - это время, а times - "раз" - так и переводится.. , для англоговорящего звучит естественно. Тут обращать на другое нужно внимание.. - здесь как "вРуби" значение (число 100) является сложным обьектом... , что для меня , например, достаточно непривычно...
-
одно но, в описание раста на сайте я такой х...ни не увидел.
-
Но увидел другое, что мне не очень понравилось... у них операторы (управляющие алгоритмические инструкции) могут возвращать значения.. само по себе это не ново.. но у них поддерживается значение "андефинед" для любого типа (подобно NULL значению в SQL), причем отсутствие его определятся отсутствием ;
-
Тут обращать на другое нужно внимание.. - здесь как "вРуби" значение (число 100) является сложным обьектом... , что для меня , например, достаточно непривычно...
Причем непонятно, чем это лучше "times(100)"... Похоже на очередное ООП головного мозга - должны быть объекты и их методы через точечку.
-
Тут обращать на другое нужно внимание.. - здесь как "вРуби" значение (число 100) является сложным обьектом... , что для меня , например, достаточно непривычно...
Причем непонятно, чем это лучше "times(100)"... Похоже на очередное ООП головного мозга - должны быть объекты и их методы через точечку.
Ну на этот вопрос по старой памяти я могу наверное ответить. - преимущество в возможности сцеплениий операций (формировании выражений из них) - этим говном руби славится... лично для меня это страшный геморр... , но скажем, так - для оберонщегов гемором являются и правила по которым создаются выражения языка си ( куча операторов присваивания с возможностью вложения в ввыражениях, инкремента, 15 приоритетов операций, слабая типизация... - которые делают возможным сотавление трудночитаемых выражений с многочисленными побочными эффектами... так, что грехопадение "рубивцев" основано на весьма старых традициях...
-
Нет здесь никакой ошибки... ибо четко сказано "Here's some code that prints "Hello" 100 times:"... time - это время, а times - "раз" - так и переводится.. , для англоговорящего звучит естественно.
Ошибка не здесь, а в той статье, что привёл Jordan:
Сравнение D и Rust
http://versusit.ru/rust-vs-d
Посмотрим теперь, как будет выглядеть код, выводящий числа от 0 до 10. На Rust это будет так:
fn main() {
for 100.times {
io::println("Hello");
}
}
На D аналогичный код бы выглядел следующим образом:
void main() {
for (int i = 0; i < 10; i++) {
writeln("Hello");
}
}
for 100.times {
io::println("Hello");
}
Выводит Hello 10 раз, но из написанного это непонятно. Откуда взялось 100 и time?
Тут обращать на другое нужно внимание.. - здесь как "вРуби" значение (число 100) является сложным обьектом... , что для меня , например, достаточно непривычно...
А я уже привык, хоть и не рубист...
-
Тут обращать на другое нужно внимание.. - здесь как "вРуби" значение (число 100) является сложным обьектом... , что для меня , например, достаточно непривычно...
Причем непонятно, чем это лучше "times(100)"... Похоже на очередное ООП головного мозга - должны быть объекты и их методы через точечку.
Я тоже раньше думал что ересь. Но поимев некоторый опыт на Lua понял таки в чем профит.
Такая запись позволяет писать цепочки функций самым естественным и прямолинейным образом. Это очень удобно.
form_module = BOM..assert(form_struct.read(3)):sub(2, -2):gsub('""', '"') (https://bitbucket.org/boris_coder/1c-toolkit/src/439a652a759be0bc7d421eeb8cb492c76aafd086/lua/cf_tools/cf_inside.lua?at=default#cl-121)
form_struct.read(3) - читаем некую строку
:sub(2, -2) - обрезаем по одному символу слева и справа
:gsub('""', '"') - заменяем удвоенные кавычки
-
И прошу обратить внимание на ассерт. Он возвращает значение, которое ему передали.
-
Я тоже раньше думал что ересь. Но поимев некоторый опыт на Lua понял таки в чем профит.
Такая запись позволяет писать цепочки функций самым естественным и прямолинейным образом. Это очень удобно.
По поводу "естественности" можно поспорить.
a().b().c() vs c(b(a()))
Лично для меня ни одна из записей не имеет однозначных преимуществ, если не рассматривать конкретное применение.
P.S. Хотя в копилку "методы с точкой" можно положить автокомплит ;)
-
Все познается в сравнении: ;)
form_module = BOM..assert(form_struct.read(3)):sub(2, -2):gsub('""', '"')
form_module = BOM..gsub(sub(assert(form_struct.read(3)), 2, -2), '""', '"')
-
И прошу обратить внимание на ассерт. Он возвращает значение, которое ему передали.
Ага. Смотрится крайне неестественно ;)
-
Глупости какие. Что мешает сделать инфиксный оператор который будет сцеплять выражения?
Ну, то есть точка нафиг не нужна, нужно чтобы просто функция times возвращала значение. См. тот же operator << для того же cout'а в плюсцах. Ну или там + какой-нибудь.
-
А как это должно выглядеть? Что-то не очень понимаю.
Хотя нафига в Rust for нужен я тоже не понял.
В Ruby то все просто:
count.times {print " hello! "}
-
См. тот же operator << для того же cout'а в плюсцах.
И чем это лучше точки?
-
См. тот же operator << для того же cout'а в плюсцах.
И чем это лучше точки?
Тем, что это не в языке.
Ну и семантику связывания выражений можно сделать любую.
-
Я частенько тоже в хацкеле так делаю, хоть это и не ООП-язык:
process fname = do
putStrLn $ "Processing " ++ fname ++ " ..."
dat <- readFile fname
let dat2 = dat
|> lines
|> map (map (\c -> [c]))
|> map (map (\s -> if s == "\t" then "\t0" else s))
|> map concat
|> map words
|> filter (\xs -> length xs > 6)
|> map (\(time: inorg:incompr:intransm:outorg:outcompr:outtransm:_) ->
(time,[inorg,incompr,intransm,outorg,outcompr,outtransm]))
|> map (\(time, xs) -> (take 2 (if length time == 5 then '0':time else time)
,map (read :: String -> Int) xs))
|> groupBy (\(t1, _) (t2, _) -> t1 == t2) -- сгруппируем по часам
|> map (\xs -> (fst $ head xs, map snd xs))
|> map (\(time, xs) ->
(time, map (\[inorg,incompr,intransm,outorg,outcompr,outtransm] ->
(inorg,incompr,intransm,outorg,outcompr,outtransm)) xs))
|> map (\(time, xs) -> (time, unzip6 xs))
|> map (\(time, (inorg,incompr,intransm,outorg,outcompr,outtransm)) ->
(time, [inorg,incompr,intransm,outorg,outcompr,outtransm]))
|> map (\(time, xs) -> (time, map sum xs))
|> map (\(time, xs) -> (time, map (\x -> trunc3 $ fromIntegral x / (1024*1024::Double)) xs))
|> map (\(time, xs) -> unwords' (time:(map show xs)))
writeFile (fname ++ ".out") $ unlines dat2Здесь оператор |> создаёт конвейер типа как pipe в юниксовой консоли. Его можно по сути считать в данном случае точкой, разделяющей объект и вызов его метода в том же Расте.
Проблема таких конвейерных обработок -- через какое-то время трудно понять что там задумывалось, даже более того -- стоит отвлечься на что-то во время написания этого кода -- и уже приходится соображать, что надо дальше в этом конвейере сделать.
Так что иногда всё же вставляю дополнительные переменные, указываю их тип, а то начинаю париться с этими типами ))
Ну, для одноразовых скриптиков можно и так наговнякать )))
-
2 valexey
А наличие оператора << и его перегрузка - это значить не "в языке" ? :)
Я к тому, что неприятие методов у традиционно простых типов чисто психологический. (имхо)
Кроме того не обязательно думать о них как о методах.
В той же Lua - это просто сахар ради удобства.
Например библиотечную функцию sub можно вызвать и так:
string.sub(mystring, i, j)
и так:
mystring:sub(i, j)
Т.е. двоеточие - это тупо сокрытие первого аргумента и обращение к нему как к объекту. Просто другая форма записи.
-
Здесь оператор |> создаёт конвейер типа как pipe в юниксовой консоли.
Кстати да. У меня тоже такая ассоциация :)
-
Я частенько тоже в хацкеле так делаю, хоть это и не ООП-язык:
process fname = do
putStrLn $ "Processing " ++ fname ++ " ..."
dat <- readFile fname
let dat2 = dat
|> lines
|> map (map (\c -> [c]))
|> map (map (\s -> if s == "\t" then "\t0" else s))
|> map concat
|> map words
|> filter (\xs -> length xs > 6)
|> map (\(time: inorg:incompr:intransm:outorg:outcompr:outtransm:_) ->
(time,[inorg,incompr,intransm,outorg,outcompr,outtransm]))
|> map (\(time, xs) -> (take 2 (if length time == 5 then '0':time else time)
,map (read :: String -> Int) xs))
|> groupBy (\(t1, _) (t2, _) -> t1 == t2) -- сгруппируем по часам
|> map (\xs -> (fst $ head xs, map snd xs))
|> map (\(time, xs) ->
(time, map (\[inorg,incompr,intransm,outorg,outcompr,outtransm] ->
(inorg,incompr,intransm,outorg,outcompr,outtransm)) xs))
|> map (\(time, xs) -> (time, unzip6 xs))
|> map (\(time, (inorg,incompr,intransm,outorg,outcompr,outtransm)) ->
(time, [inorg,incompr,intransm,outorg,outcompr,outtransm]))
|> map (\(time, xs) -> (time, map sum xs))
|> map (\(time, xs) -> (time, map (\x -> trunc3 $ fromIntegral x / (1024*1024::Double)) xs))
|> map (\(time, xs) -> unwords' (time:(map show xs)))
writeFile (fname ++ ".out") $ unlines dat2Здесь оператор |> создаёт конвейер типа как pipe в юниксовой консоли. Его можно по сути считать в данном случае точкой, разделяющей объект и вызов его метода в том же Расте.
Проблема таких конвейерных обработок -- через какое-то время трудно понять что там задумывалось, даже более того -- стоит отвлечься на что-то во время написания этого кода -- и уже приходится соображать, что надо дальше в этом конвейере сделать.
Так что иногда всё же вставляю дополнительные переменные, указываю их тип, а то начинаю париться с этими типами ))
Ну, для одноразовых скриптиков можно и так наговнякать )))
Слушай, ну монады же ровно про это же. Какая-нибудь List например. В плюсах мне лично дико мешает, что там есть statement'ы.
-
Слушай, ну монады же ровно про это же. Какая-нибудь List например.
Да куда ж там монады-то воткнуть? List -- для хитроумной генерации списков годится, для Maybe тут надобности нет, прочие монады как сюда воткнуть -- тоже ума не приложу...
Просто серия преобразований данных и всё... Никаких монад вроде не нужно...
-
.....
Лично для меня ни одна из записей не имеет однозначных преимуществ, если не рассматривать конкретное применение.
P.S. Хотя в копилку "методы с точкой" можно положить автокомплит ;)
а речь идет именно о конкретных применениях - точнее так.. использование цепочных выражений для ряда задач обеспечивает естественную запись алгоритма ( записанного в терминах предметной области задачи). Но разумеется из этого не следует, что такую запись надо насаждать (как ООП в шарпе или в руби). И тут же ответ на вопрос Бориса - нафига нужен for.... - для тех случаев когда эта конструкция естественным образом отображает алгоритм - учитывайте, что решения одной и той же задачи может описываться в рамках различных систем понятий, теорий (которые по разному моделируются алгоритмами).
-
Да не. Я имел в виду нафиг там for конкретно в этой конструкции. Оно ведь явно с руби скомунизжено, а там сам times и есть цикл. Слово for просто лишнее.
Хотя там видимо семантика различная таки... В руби n.times - это функция, которая принимает чанк и выполняет его n раз. В расте же for судя по всему принимает итератор, и n.times его соответственно создает. Т.е. выглядит похоже, но работает унутри не так. Ну т.е. в расте times сам по себе видимо бесполезен