LINUX.ORG.RU
ФорумTalks

Образец годного ЯП

 ,


0

7

Итак, по прошествии некоторого времени у меня выработался ряд предпочтений к тому инструменту, с которым я работаю:

1. Ни в коем случае не интерпретируемый/скриптовый: сложно соблюдать правила «хорошего тона» при написании кода. В случае с компилируемым языком - у меня есть компилятор, который даст по рукам если что.

2. Обязательно наличие строгой статической типизации: никаких int = double быть не должно. Желательно иметь о подобном предупреждение по дефолту. В идеале - сообщение об ошибке.

3. Желательна, но не обязательна объектная ориентированность: цель структурирование кода, настоящая модульность.

4. Желательно наличие REPL дабы можно было на лету проверять свои догадки и предположения о тех или иных аспектах кода.

5. Мэйнстримный: брейнфаки идут лесом ибо некому сопровождать и поддерживать код.

1. Каковы ваши предпочтения?

2. Есть ли что-нибудь удовлетворяющее этим пунктам?

Дискасс.

★★★★★

Последнее исправление: LongLiveUbuntu (всего исправлений: 1)

SML или OCaml.

ymn ★★★★★
()

int = double быть не должно.

Почему? что плохого допустим в приведении типов си int i=(int)j;?

Вообщем Си вам в руки :) Это почти идеальный язык я щитаю.

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

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

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

Про undefined behavior в нежно обожаемых здесь С/С++ не слышал ничего?

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

Мне не стыдно даже за такой тред

Это потому что у вас совести нет.

ya-betmen ★★★★★
()
Ответ на: комментарий от blogdron

что плохого допустим в приведении типов си int i=(int)j;?

В явном приведении ничего плохого нет.

Вообщем Си вам в руки :) Это почти идеальный язык я щитаю.

Ты точно ОП читал?

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

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

AFAIK, там вполне полноценный байткодовый интерпретатор. Впрочем, в данном контексте это не так важно - главное, что интепретатор есть,

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

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

ymn ★★★★★
()

Нет верификации кода - не нужен.

ranka-lee
()
Ответ на: комментарий от ymn

с оптимизирующим компилятором в нейтив дела обстоят не очень.

А что с ним не так? Кстати, ты же вроде живой пользователь Ocaml - Ocaml platform взлетела или просто рано делать выводы?

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

А что с ним не так?

ну по сравнению с SML/NJ и схемовским сталином, это не оптимизирующий компилятор, а транслятор байткода в машинные коды.

Ocaml platform взлетела или просто рано делать выводы?

А хз, я особо не интересовался. В caml-list, емнип, давненько ничего о ней не слышно.

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

Это обрезок ocaml

Наоборот, F# это допиленный ocaml.

да еще и под одну только платформу

Под mono тоже есть, а это over9000 платформ.

Reset ★★★★★
()

В случае с компилируемым языком - у меня есть компилятор, который даст по рукам если что.

Своей головой надо думать, как твоя программа работает, компилятор тебя не спасёт.

Обязательно наличие строгой статической типизации: никаких int = double быть не должно.

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

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

Ну так найди мой код и развей подозрения.

Зачем? У меня картина мира вполне консистентная, никаких проблем.

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

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

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

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

== бросать исключение

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

В общем, мне периодически хочется иметь два API — одно на эксепшенах, второе на кодах возврата. Потому что иногда мне удобнее одно, иногда другое.

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

В ocaml'е «батареек» нет из коробки, да и уродств полно, типа того же '+.'. В общем, F# гораздо приятней.

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

В ocaml'е «батареек» нет из коробки, да и уродств полно, типа того же '+.'.

Проблема в том, что их там нет «из коробки», но вообще они есть, причём ставятся тривиально. А F# — кастрированный диалект.

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

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

Подобной фичи (читай функторы над модулями) я нигде не видел.

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

Смотря что считать уродством) Есть revised syntax, а +. это для эстетов-любителей строгой типизации.

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

А «уродства» как из ocaml'а выпилить?

Их там относительно немного. Кое-что уже выпилено, кое с чем приходится мириться.

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

Проблема в том, что их там нет «из коробки»

Проблема в том что на окамле программировать сложнее, чем на хаскеле.

Да и существует он на данный момент, только потому что существует Coq.

Индустрия что-то пытается. По крайней мере Окамл дает намного больше гарантий успешности, чем хаскель... Но пока ничего кроме элитиссхого языка — секретного оружия из него не вышло.

Хаскель же, вообще оторван от подлежащей аппаратной архитектуры, как громадным стеком кодогенерации, так и пресловутой подсистемой ввода-вывода. Кстати, именно поэтому на нем так просто получаются параллельные/конкурентные приложения. Именно поэтому он и может претендовать на идеальный язык... Ну, до тех пор, пока не потребуются 100% гарантии работоспособности ;)

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

Проблема в том что на окамле программировать сложнее, чем на хаскеле.

Согласен.

Да и существует он на данный момент, только потому что существует Coq.

Здрасьте, а Jane Street куда подевали?

Ну, до тех пор, пока не потребуются 100% гарантии работоспособности

Как раз Haskell более чем работоспособен.

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