Size: a a a

Compiler Development

2020 February 12

p

polunin.ai in Compiler Development
>на питоне принято не вывихивать мозг читающему
>Django
источник

МБ

Михаил Бахтерев in Compiler Development
Peter Sovietov
(в сторону) Любопытно, почему именно этот чат столь привлекает любителей троллинга и задушевных бесед обо всем, кроме компиляторов. %)
Потому что людям внутренне важно написать "правильный" компилятор. А "правильное" для нашего человека - это бесспорное :) Эх. Надо всех учить топосам, чтобы не было иллюзий об единственности истины.
источник

МБ

Михаил Бахтерев in Compiler Development
polunin.ai
>на питоне принято не вывихивать мозг читающему
>Django
Тервер как-бы. Единичный случай не демонстрирует общую тенденцию.
источник

p

polunin.ai in Compiler Development
Peter Sovietov
(в сторону) Любопытно, почему именно этот чат столь привлекает любителей троллинга и задушевных бесед обо всем, кроме компиляторов. %)
Говорить о базовых вещах - скажут "иди гугли"
Говорить о сложных вещах - сложно
источник

p

polunin.ai in Compiler Development
Михаил Бахтерев
Тервер как-бы. Единичный случай не демонстрирует общую тенденцию.
Этим единичным случаем пользуется четверть питонистов🤷🏿‍♂
источник

YS

Yuriy Syrovetskiy in Compiler Development
Михаил Бахтерев
НууууУуу. Очень спорное утверждение. Когда в Haskell легко встретить четыре fmap и три <> в одном выражении t с свершенно разными смыслами. Выражение t, конечно, можно разобрать на языке функторов и моноидов, но для понимания вычислительго смысла t часто нужно потратить несколько часов, потому что сверху же ещё навалена кучка изощрённых расширений с нестандартными deriving-ами. И это проблема. В Си++ не такой бешенный автоматический уровень абстракций, обычно. Проблема не в сложности самого языка, а в том, как его используют. На Питоне тоже можно вывихнуть мозг читающему, но просто не принято это делать. В Haskell, к сожалению, другая культура разработки библиотек.
да, бывает. лично я стараюсь в таких случаях дописывать типы или специализировать тот же fmap, имли имелся в виду конкретный тип
источник

YS

Yuriy Syrovetskiy in Compiler Development
Михаил Бахтерев
НууууУуу. Очень спорное утверждение. Когда в Haskell легко встретить четыре fmap и три <> в одном выражении t с свершенно разными смыслами. Выражение t, конечно, можно разобрать на языке функторов и моноидов, но для понимания вычислительго смысла t часто нужно потратить несколько часов, потому что сверху же ещё навалена кучка изощрённых расширений с нестандартными deriving-ами. И это проблема. В Си++ не такой бешенный автоматический уровень абстракций, обычно. Проблема не в сложности самого языка, а в том, как его используют. На Питоне тоже можно вывихнуть мозг читающему, но просто не принято это делать. В Haskell, к сожалению, другая культура разработки библиотек.
это либо преждевременное обобщение, тогда надо специализировать, либо действительно высокоуровневый комбинатор, тогда надо абстрагировать — вынести и дать имя.

в общем, известно, как с этим бороться.

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

p

polunin.ai in Compiler Development
Yuriy Syrovetskiy
это либо преждевременное обобщение, тогда надо специализировать, либо действительно высокоуровневый комбинатор, тогда надо абстрагировать — вынести и дать имя.

в общем, известно, как с этим бороться.

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

FO

FORTRAN ONE LOVE in Compiler Development
polunin.ai
Поэтому нужно использовать Rust. Синтаксис ближе к родному Си-подобному, по сложности изучения проще хаскелля, а скорость на уровне того же Си.
А в Rust OpenMP и OpenACC затащили?
источник

МБ

Михаил Бахтерев in Compiler Development
Yuriy Syrovetskiy
это либо преждевременное обобщение, тогда надо специализировать, либо действительно высокоуровневый комбинатор, тогда надо абстрагировать — вынести и дать имя.

в общем, известно, как с этим бороться.

а в С++ очень много низкоуровневых концепций, которые надо применять все вместе и никак не спрятать
Вот потому, что многое невозможно спрятать, такой код и читается легче. Человеку проще проассоциировать некий гештальт с изображением кода, пускай и избыточным, а потом по мере необходимости разбирать это изображение на части глазками, чем в голове держать разный смысл для одинаково выглядящих текстовых конструкций.
источник

p

polunin.ai in Compiler Development
FORTRAN ONE LOVE
А в Rust OpenMP и OpenACC затащили?
Let me 🔎 Google that for you:
🔎 OpenMP in Rust
источник

FO

FORTRAN ONE LOVE in Compiler Development
polunin.ai
Let me 🔎 Google that for you:
🔎 OpenMP in Rust
Значит нет
источник

МБ

Михаил Бахтерев in Compiler Development
polunin.ai
Поэтому нужно использовать Rust. Синтаксис ближе к родному Си-подобному, по сложности изучения проще хаскелля, а скорость на уровне того же Си.
Дело никогда не в синтаксисе. Дело всегда в семантике. А семантика Раст мешает его использовать эффективно
источник

p

polunin.ai in Compiler Development
Михаил Бахтерев
Вот потому, что многое невозможно спрятать, такой код и читается легче. Человеку проще проассоциировать некий гештальт с изображением кода, пускай и избыточным, а потом по мере необходимости разбирать это изображение на части глазками, чем в голове держать разный смысл для одинаково выглядящих текстовых конструкций.
public const operator[](const *vector<&int> v) const
Меня от такого кода бросает в дрожь, не знаю как вас.
источник

p

polunin.ai in Compiler Development
Михаил Бахтерев
Дело никогда не в синтаксисе. Дело всегда в семантике. А семантика Раст мешает его использовать эффективно
Конструктивные аргументы будут?
источник

YS

Yuriy Syrovetskiy in Compiler Development
polunin.ai
Поэтому нужно использовать Rust. Синтаксис ближе к родному Си-подобному, по сложности изучения проще хаскелля, а скорость на уровне того же Си.
1. использовать для чего? для чтения чужого кода? чужой код уже написан на своём языке.
2. синтаксис — дело привычки.
3. сложнее Хаскеля из-за необходимости описывать память и владение.
4. скорость работы не влияет на читабельность.
источник

YS

Yuriy Syrovetskiy in Compiler Development
Михаил Бахтерев
Вот потому, что многое невозможно спрятать, такой код и читается легче. Человеку проще проассоциировать некий гештальт с изображением кода, пускай и избыточным, а потом по мере необходимости разбирать это изображение на части глазками, чем в голове держать разный смысл для одинаково выглядящих текстовых конструкций.
хм, у меня противоположное впечатление. мне проще в голове разбить и понять малое, чем большое
источник

МБ

Михаил Бахтерев in Compiler Development
polunin.ai
Конструктивные аргументы будут?
Эмс. Это личный опыт. Пробовал писать системный код на нём, и не осилил без unsafe. А если у меня поливна кода unsafe, зачем мне остальное?  Объективно можно посравривать код на Rust с кодом на Си, хотя бы в BenchmarksGame. Ну, или Servo с аналогиным куском Chromium.
источник

p

polunin.ai in Compiler Development
Yuriy Syrovetskiy
1. использовать для чего? для чтения чужого кода? чужой код уже написан на своём языке.
2. синтаксис — дело привычки.
3. сложнее Хаскеля из-за необходимости описывать память и владение.
4. скорость работы не влияет на читабельность.
1. Для написания новых проектов.
2. Может и для вас, для меня нет. Пишу на c# около полугода, мне его синтаксис до сих пор не нравится.
3. Не понял, что нужно дополнительно описывать? В с++ вы описываете * и & тоже.
4. Я после месяца его изучения мог понять с помощью IDE любую программу, написанную на нем (кроме async-программ, но там свой мир).
источник

KR

K R in Compiler Development
Михаил Бахтерев
Эмс. Это личный опыт. Пробовал писать системный код на нём, и не осилил без unsafe. А если у меня поливна кода unsafe, зачем мне остальное?  Объективно можно посравривать код на Rust с кодом на Си, хотя бы в BenchmarksGame. Ну, или Servo с аналогиным куском Chromium.
Ну другая половина то safe.
источник