LINUX.ORG.RU

Подскажите ЯП.


1

3

Есть желание познакомится с новым языком программирования. Цель использования — программирование «для себя». Что хочу — максимум синтаксического сахара, ООП, лёгкие биндинги С либ, мультипарадигменность желательна, есс-но свободный и есс-но с компиляторами, очень желательно и с IDE тоже, под онтопик.

★★★★★

Так же желательно наличие строгой статической типизации.

next_time ★★★★★ ()

Очень жалко, но, кроме скалы, по-моему, тебе ничего не подходит.

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

Тогда, не могли бы вы привести на вскидку несколько достоинств Окамла? По возможности, в сравнении с Falcon/Rust, см. чуть выше.

next_time ★★★★★ ()

Hit the road, Jack... just Mono, Mono, Mono.

fang90 ★★★★★ ()

максимум синтаксического сахара
ООП
лёгкие биндинги С либ
мультипарадигменность желательна
под онтопик
с IDE

Тебе нужен C#.

Redrum ()
Ответ на: комментарий от next_time

А, черт, я думал, тебе нужна IDE, а не туча костылей к какому-нибудь эмаксу.

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

Может я что-то упускаю, но там вроде вообще плоховато с сахаром, нет?

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

кроме скалы, по-моему, тебе ничего не подходит

Особенно по пункту «лёгкие биндинги С либ» хорошо подходит. А чем C#/Mono хуже будет?

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

Смотря что понимать под сахаром. Вообще почти весь синтаксис питона — сахар над словарями.

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

Не знаю, я с до-диезом знаком шапочно, а все, что помню - это какой-то прибитый костылями linq и глобальный фап всех сишарпщиков на async/await, хотя, может, я просто не вошел во вкус.

cdshines ★★★★ ()
Последнее исправление: cdshines (всего исправлений: 1)
Ответ на: комментарий от cdshines

вы правильно думали, просто ради красоты языка я готов даже пойти на использование емакс-а отказаться от иде и писать в gedit-e

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

По возможности, в сравнении с Falcon/Rust, см. чуть выше.

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

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

хз, мне не очень нравится ml-синтаксис. я пробовал sml - оно, конечно, расширяет сознание, но я толком не настроил ни эмакс, ни sublime. пишу вот в идее на скале)

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

К шарпу боюсь особо привязываться, это раз. Во-вторых, писать всё время public и break (кто в курсе, тот поймёт) — не моё, от таких вещей я и пытаюсь убежать.

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

стабильной версии.

да и бог с ней. готов рассматривать самые фриковские и малораспространённые варианты: для себя же

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

боюсь особо привязываться,

боюсь в плане на линуксе, это ж майкрософтовская поделка, в любой момент всё может лесом пойти

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

тогда, к вам тот же вопрос: почему не окамл?

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

next_time ★★★★★ ()

Еще можно хаскель, если хочется мозги подрочить.

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

Не знаю окамл. В любом случае лучше уж F# тогда.

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

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

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

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

OCaml старее, поэтому, объективно, более популярен и богат батарейками.

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

А ты попробуй не ООП язык, на этой парадигме свет клином не сошёлся.

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

Вроде тот же окамл, но с нормальной IDE и от нормального производителя.

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

Вроде тот же окамл

Нет

с нормальной IDE

Это с какой?

от нормального производителя

Сомнительно.

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

OCaml старее, поэтому, объективно, более популярен

увы, но внезапно, нет: под Rust уже плагин намутили для эклипс, а под Окамл придётся в gedit-е писать

богат батарейками.

под батарейками вы уже написанные либы имеете в виду? так ведь я не зря спрашивал про биндинги к С, у Rust-а с этим вроде всё ок

Мне вообще, хотелось бы узнать про киллер-фичи OCaml-a, т.е., пример интересного сахара

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

под Rust уже плагин намутили для эклипс, а под Окамл придётся в gedit-е писать

http://ocamldt.free.fr/ — первая ссылка в гугле по запросу «ocaml eclipse plugin»

под батарейками вы уже написанные либы имеете в виду?

Да

так ведь я не зря спрашивал про биндинги к С

С этим тоже, вроде, всё нормально, но я не пользовался.

про киллер-фичи OCaml-a

Прежде всего это язык ФП, «энергичный», применение императивных приёмов может дать неожиданный результат, однако тут http://caml.inria.fr/pub/docs/oreilly-book/ написано, как этого избежать.

olibjerd ★★★★★ ()
Последнее исправление: olibjerd (всего исправлений: 1)
Ответ на: комментарий от PolarFox

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

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

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

Декларативный гуй лучше ООП гуя. Даже кутиразрабы это поняли и создали qtquick.

PolarFox ★★★★★ ()

Lisp. Только сахара нет, синтаксиса тоже.

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

первая ссылка в гугле по запросу «ocaml eclipse plugin»

ох спасибо, что-то я не догадался именно так искать

применение императивных приёмов может дать неожиданный результат, однако тут http://caml.inria.fr/pub/docs/oreilly-book/ написано, как этого избежать.

дважды спасибо, почитаю

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

Вот именно после qtquick я и стараюсь держаться подальше от не ООП концепций в разработке гуя. Кроме того, кроме qtquick других не ООП гуйных систем не замечено, да и в квик вполне есть ООП, только оно там какое-то особое, уличное.

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

- Посоветуйте язык с максимумом сахара и ООП

- Лисп, только там ни сахара, ни ООП

next_time ★★★★★ ()

Vala, если еще не советовали.

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

в целом неплохой язык, но на ИДЕ к ней почему-то все успешно положили + шарпопроблемы

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

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

сравни описание интерфейса на Qt/C++ и QML. не очень заметно, как там выигрывает ООП

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

- Лисп, только там ни сахара, ни ООП

Да, да, вообще там ничего нет. Нaфига он такой нужен вообще. Одним словом — БорщеЛишп.

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

И где там ООП?

есть динамическая диспетчеризация в виде встроенного в язык паттерна Visitor, плюс отличная реализация интерфейсов

мультипарадигменность?

по разброду в стилях уступает разве что C++

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

Вот как раз сейчас в свободное время пишу гуй (хотя, свободного времени мало + ЛОР), от QML пришлось отказаться и переписать с нуля.

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