строгая статическая типизация

Что ты называешь «скриптовым языком»?

Интерпретируемые?

Чуть выше поправили - интерпретируемые.

На самом деле не принципиально, чтобы это был прямо классический интерпретатор, принципиально только отсутствие этапа ручной компиляции/трансляции.

И как оно проверит типы без компиляции? Статический анализатор нужен, по сути.

принципиально только отсутствие этапа ручной компиляции/трансляции

а что мешает в обертке при запуске «скрипта» откомпилировать, а потом запустить временный бинарь?

принципиально только отсутствие этапа ручной компиляции/трансляции

Go.

Получаем по идеологии что-то напоминающее яву.

принципиально только отсутствие этапа ручной компиляции/трансляции.

Что значит «ручной»? Вот в Python есть компиляция - она ручная или дикая? :)

Иными словами:

% cat myprog.d
#!/usr/bin/env rdmd
import std.stdio;
void main()
{
    writeln("Hello, world with automated script running!");
}

Катит за скриптовый язык?

да, вполне катит. то, что нужно. спасибо.

Haskell.

haskell или Go Еще вроде mypy для чего-то подобного сделали, но я не интересовался

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

да, вполне катит. то, что нужно. спасибо.

scala в таком режиме тоже работает

Такие трюки много с чем прокатывают: http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html

#!/usr/bin/env runhaskell

{-# LANGUAGE OverloadedStrings #-}

import Turtle

main = do
    mkdir "test"
    output "test/file.txt" "Hello!"
    proc "tar" ["czf", "test.tar.gz", "test"] empty

А если считать «скриптингом» скриптование внутренней логики приложения, есть вот такое сокровище: https://github.com/gluon-lang/gluon

typed racket

А если считать «скриптингом» скриптование внутренней логики приложения, есть вот такое сокровище: https://github.com/gluon-lang/gluon
UTF-8 by default - Gluon supports unicode out of the box with utf-8 encoded strings and unicode codepoints as characters.

TRIGGERED!!!!11

$ runghc your_puper_programme.hs

Туда же fsharpi/fsi, scala.

Hack, да и Java туда же.

C#

C — Cling

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

да и Java туда же.

c этого места поподробнее. там же нужно .class/.jar собрать, или я что-то упустил?

там разве можно пропустить этап создания .exe ?

Да, там все что угодно можно.

там же нужно .class/.jar собрать, или я что-то упустил?

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

C - tcc

haskell

Обероны оберон_сред все такие.

c этого места поподробнее. там же нужно .class/.jar собрать, или я что-то упустил?

https://blogs.oracle.com/java/jshell-and-repl-in-java-9

http://www.javarepl.com/term.html

Лол, Haskell, OCaml, Scala.

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

Вот только зачем тебе это?

А зачем вообще проверки типов? Вот и здесь затем же.

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

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

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

И да. По твоему лучше переписать всю скриптовую часть линукса с sh на С и оставить одни бинарники? Охренеть, какая гибкая и удобная система получится. А если заменить это на статически-типизируемую скриптоту, то может заметно упасть производительность. У скриптоты есть своя ниша.

Проверка типов замечательная операция, но она долгая

А в секундах это сколько? И сколько стоит запуск скрипта, который потом рухнет с AttributeError?

Тут же это будет тормозить каждый запуск скриптов.

«Тут» - это где? Например, в Python при старте исходник транслируется в байткод. Проверка типов (mypy) производится при трансляции, поэтому при последующих запусках накладных расходов на нее не будет. Так что... всё нормально.

По твоему лучше переписать всю скриптовую часть линукса с sh на С и оставить одни бинарники?

Что именно в моих словах натолкнуло тебя на эту мысль?

У скриптоты есть своя ниша.

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

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

Допустим, стоит задача: изменить тип в рантайме, таким образом, чтобы клиент, который ранее не работал(не мог) с этим типом стал работать с ним. Не важно, считает ли кто-то, что это нужно или нет, но это формально определенный класс задач. Для решения (например) этого класса задач, язык __обязан__ быть динамически-типизированным

Допустим, стоит задача: изменить тип в рантайме

Это не задача, а решение. Плохое решение.

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

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

Да. Но именно дети любят играть со спичками.

Да, да. А когда обжигаются, бегут к маме, и жалуются на спички, требуют их запретить

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

Да. Но именно дети любят играть со спичками.

Да, да. А когда обжигаются, бегут к маме, и жалуются на спички, требуют их запретить

Это в лучшем случае. А могут устроить пожар и сказать маме «смотри, как красиво я умею».

У си не строгая типизация

sed: всё строго относится к типу «строка»