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

Rust был бы идеальным, если бы не эти ужасные строки, unwrap'ы и нечитаемая каша в сигнатурах функций

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

C++ не имеет автоматического управления памятью

Имеет, надо просто осилить RAII, а не писать как на C

swift сделали очень хорошим, почти идеальным. За исключением работы со строками + кучка мелких неудобств, которые скорее всего допилят в будущем.

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

Вангую, что им станет CSS. Причём уже эдак к седьмой версии.

begin/end удобнее '{'?

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

Сабж. Интересно, как ЛОРовцы представляют себе идеальный на их взгляды ЯП.

Недавно видел на хабре статью от интел в которой рассказывают как на JavaScript делать умножение, деление и всякие другие вещи что бы они оптимально выполнялись на «самойлудшей архитектуре на земле». А еще я недавно получил переполнение стека (или что то типа того) на обычных заменах.

- Это высокоуровневое программирование? Это ООП? Говно какое то... В связи с этим думаю что бесполезно велосипедить какой то там идеальный язык, все равно получится херня. Нужен комплексный подход что бы машина была спроектирована так что бы из нее вот это все говно не вылезало - ориентировать ее на языки высокого уровня, интерпритатор делать прямиком в машкод, размещается пусть хоть в гипервизоре (как у эльбрусов), хоть в ядре ОС (в ядре конечно предпочтительнее), но чтобы оно идеально знало архитектуру с которой работает и тогда можно думать об изобретениях сфеерических в вакууме идеальных языков.

вглядывайся в эту мелкоту

Очки и подсветка синтаксиса спасут ацца русской к-эфиродинамики %)

Rust был бы идеальным, если бы не эти ужасные строки, unwrap'ы и нечитаемая каша в сигнатурах функций

Для системного языка строки и обработка ошибок наоборот прекрасны же. Про ошибки - не используй unwrap`ы вообще - или обрабатываешь ошибку нормально, или грохаешь все expect`ом с человекопонятным описанием проблемы, или пробрасываешь ошибку наверх. Ну и каши в сигнатурах, по сравнению с подобными языками, нет.

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

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

Мамку твою.

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

css это только интерфейсная часть.

Мамку твою.

Недели пятиклассников на ЛОРе. Ничего, скоро вам в школу. А там с утра - учёба, после обеда - дотка. Некогда будет. :-D

Недели пятиклассников на ЛОРе. Ничего, скоро вам в школу. А там с утра - учёба, после обеда - дотка. Некогда будет. :-D

Меня трудно найти и легко потерять!

Посмотри под стулом, есть мнение, что проблема там :}

Под твоим? Физически не могу, давай уж сам.

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

Включение дурачка это твоя профессия или талант? :3

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

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

Исходные тексты на естественном языке.

Слишком многословно. И да, 1С.

Голосовой ввод

НЕ НУЖНО! Представь себе какой галдеж будет в офисе стоять, плюс печатать быстрее чем говорить. А вот мыслеввод - годно было бы: представил себе алгоритм - а он уже запустился в отладчике.

П.с. Дай угадаю, ты не программист, да?

1. Сборщик мусора;
2. отсутствие сборщика мусора.

То бишь возможность поделить на ноль?

На ноль почти везде можно делить.

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

Но везде это вызовет фатальную ошибку.

Но везде это вызовет фатальную ошибку.

Да просто исключение вылетит. Его же легко поймать можно.

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

Искоробочную однобитовую математику применимую к любым типам данных (variable_a.7=variable_a.12 ^ variable_b.23), ну и ещё какие-нибудь искоробочные типы данных и операции для DSP, чтобы какой-нибудь FIR или там QPSK декодер выглядел просто и наглядно, а не как сейчас.

все выдающиеся возможности erlang + ООП

+ в разумных примесях: python, php, java, c, c++, rust ...

Очки и подсветка синтаксиса спасут ацца русской к-эфиродинамики %)

Ты ещё микроскоп и 3-д очки посоветуй для «правильного» ЯП.

Почему бы просто не увеличить шрифт? И да, в этом мире всё в первую очередь делается из расчёта на здоровых людей. Для людей с плохим зрением производятся очки, чтобы те могли работать с тем, что разработано для людей с хорошим зрением. Поэтому шутка про 3D-очки и микроскоп тут не в тему.

блекджек и шлюх(читай хороший синтаксис, понятный и приятный)

И да, в этом мире всё в первую очередь делается из расчёта на здоровых людей.

Ты серьёзно считаешь что у программистов с++ нет никаких профзаболеваний и зарплату им платят за удовольствие погромировать на хорошем языке?

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

Ещё как в тему. Символов в окно помещается тысячи 2 и больше, и ты утверждаешь что нужно с первого взгляда и без напрягов находить именно тот, который начинает и закрывает блок?

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

Фиксед.

А вот мыслеввод - годно было бы

А если шеф будет твои мысли читать или, упаси Столлман, Microsoft?!

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

Идеальная машина - это такая, что её вообще нет, но работа выполняется. Вероятно, идеальный язык должен давать сразу нужный объектный код под нужную платформу, без исходников, редакторов/IDE и трансляторов. Главное - сформулировать алгоритм. Из той же оперы, что и боженька.

Зачем?

+1

с самого детства считал нынешние архитектуры железяк deffective by design, не в языках проблема

Чтобы не было как в старой копипасте.

Поздно заметил ответ, извиняюсь.
Но Rust почти общего назначения язык. Много на себя берёт, а элементарные вещи реализованы настолько неудобно... Вот у новичка чтобы написать что-то сложнее «Hello World!» наверняка не получится ничего т.к. строки это самое первое, на чем они тренируются. Нужно сначала выучить ввесь Rust, а затем ещё и С, C++, чтобы толком понять что к чему и зачем.
Наверняка можно что-то с этим сделать при помощи их zero-cost абстракций, чтобы с языком было приятно работать. Может и не самый лучший пример, но вот Java пошла примерно таким путём и пришла к успеху.

Каша в сигнатурах из-за сложных структур данных. Да, я согласен, что это нормально для такого языка, но тут проблему ещё усугубляет двоеточие между именем параметра и типом.
Когда параметров много, их довольно таки сложно посчитать и намного сложнее понять, что функция принимает на вход. Неэргономично.
Есть у меня идея, предложить сделать вот так:

fn foo(x y z :i32) -> {1}
fn bar(a b :String, c d :u64) -> {"asdfa"}

fn baz() -> 42
fn new() -> SomeStruct { x: 0, y: 1 } 

Вот у новичка чтобы написать что-то сложнее «Hello World!» наверняка не получится ничего т.к. строки это самое первое, на чем они тренируются.

Новичок прочитает https://doc.rust-lang.org/book/strings.html и все у него будет хорошо, я в него верю.

Нужно сначала выучить весь Rust, а затем ещё и С, C++, чтобы толком понять что к чему и зачем.

Си и так все должны знать, от него никуда не денешься. А если знаешь Си, то ржавчина, вроде как, не должна вызвать каких-то диких трудностей в изучении.

Наверняка можно что-то с этим сделать при помощи их zero-cost абстракций, чтобы с языком было приятно работать.

Хз, лично мне с строками в ржавчине приятно работать. Ну да, есть отдельные &str и String, и иногда надо писать явное преобразование первого во второе. Ну и окей. Мне бы больше не нравились всякие неявные приведения типов.

А как ты предлагаешь упростить работу со строками? Может мы о разном говорим, что конкретно не нравится?

Может и не самый лучший пример, но вот Java пошла примерно таким путём и пришла к успеху.

Я не слишком хорошо знаком с java, но, если честно, не вижу кардинальных отличий в ржавых и явовских строках. Там тоже есть String и отдельный StringBuffer. Можно пояснить, чем оно сильно лучше?

Есть у меня идея, предложить сделать вот так

Предлагать надо было до 1.0, теперь поздно)

Как по мне — было бы идеально. Только не уверен, что другие люди согласятся...

Ээто очень спорное предложение)

Да ладно, это как {}/отступы/beginend - на такие вещи перестаешь обращать внимание через пару дней активной работы с языком.

Даже я с трудом понял, и то не по этой документации; совсем новичкам в программировании путь в этот язык закрыт.
Как вообще можно писать что-то вроде этого:

let a: String = "asdfasdfasdfa".to_string();

String a = "asdfasdfsdfa";

... В Java было бы так: String a = "asdfasdfsdfa";

Разве аналогом на ржавчине не будет просто let a = "asdfasdfsdfa";?

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

совсем новичкам в программировании путь в этот язык закрыт

Не питон, это да. Вряд ли стоит начинать знакомство с программированием с ржавчины.

Нет, так как в Java я создал строку и сразу работаю с ней

Смотря что считать «работой». :) Если не нужно владение, то с &str сразу можно работать.

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

совсем не логичные

Владение - ключевая концепция в языке, мне такое разделение видится логичным.

to_string -> to_String

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

Можно писать let s = String::from("hello");, если .to_string() не нравится и очень уж часто нужны владеющие строки.

Раньше, кстати, оно называлась to_owned(), может так понятней было, хз.

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

Вот и получается, что язык интересен в основном только половине программистов на C\C++, другая половина говорит что не взлетит, а все остальные либо не осилят, либо скажут «фу» и уйдут няшится с каким-то там Ruby или Nim.
Работа со строками: распечатать, передать аргументом, конкатенация, сравнение. Почти всегда нужно плясать с бубном; писать легко читаемый, чистый и лаконичный код не получится — факт.
Ограничение вроде «нельзя использовать» тоже плохо. Вот если бы предоставили что-то типа #[allow(Uppercase)] для таких случаев — было бы идеально.
А String надо переименовать в CharVec, судя по всему, и дать по шее тем, кто людей в заблуждения подобными названиями вводит.

Ограничение вроде «нельзя использовать» тоже плохо.

Это нынче модно, так как уменьшает вероятность некоторых споров по поводу стиля кода.

Кто будет писать #[allow(Uppercase)] перед каждой функцией? То что так нельзя делать в обычной практике но можно сделать в исключительных ситуациях, будет очевидным. Если же кто-то не поймёт — справедливо получит ошибку компиляции и побежит в гугл спрашивать, мол «почему это в std:: можно, а мне нельзя?».
Это гораздо лучше, чем думать почему вместо «string» я получаю «String».

уйдут няшится с каким-то там Ruby или Nim

Если задача людям позволяет использовать руби или ним, то ржавчина им и правда может быть мало нужна. Интересно, «Ruby или Nim» это комплимент для нима или наоборот? )

Работа со строками: распечатать, передать аргументом, конкатенация, сравнение. Почти всегда нужно плясать с бубном; писать легко читаемый, чистый и лаконичный код не получится — факт.

Ээээ

fn main() {
    // распечатать
    let a = "Мортарион";
    println!("{}", a);
    
    // передать аргументом
    f("Фулгрим");
    
    // сравнение
    let b1 = "Альфарий";
    let b2 = "Омегон";
    println!("b1 == b2? {}", b1 == b2);
    
    // конкатенация
    // вот это уже требует владения - надо же где-то хранить результат.
    // сборщика мусора, как в java, тут нет.
    let c1 = "Леман";
    let c2 = "Русс";
    let c3 = c1.to_string() + " " + c2;
    println!("{}", c3);
    
    // можно так, если больше нравится, to_string тут нет :)
    let d1 = "Корвус";
    let d2 = "Коракс";
    let d3 = format!("{} {}", d1, d2);
    println!("{}", d3);
}

fn f(s: &str) {
    println!("foo: {}", s);
}

http://is.gd/MuU2UT

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

Ограничение вроде «нельзя использовать» тоже плохо. Вот если бы предоставили что-то типа #[allow(Uppercase)] для таких случаев — было бы идеально.

#[allow(non_snake_case)], само собой, есть. Для ffi, например, используется.

А String надо переименовать в CharVec, судя по всему, и дать по шее тем, кто людей в заблуждения подобными названиями вводит.

Это же не просто массив символов, это именно строка, потому что дает кое-какие гарантии насчет содержимого.

https://www.reddit.com/r/rust/comments/2b08l5/uft8_and_string_why_vecu8