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

При наличии мозгов - да. На R например посмотри.

А зарплату платить за что?

— Степан! У гостя карета сломалась.
— Вижу, барин. Ось полетела. И спицы менять надо.
— За сколько сделаешь?
— За день сделаю.
— А за два?
— Ну… За… Сделаем и за два.
— А за пять дней?
— Ну, ежели постараться — можно и за пять.
— А за десять?
— Ну, барин, ты задачи ставишь! За десять дён одному не справиться, тут помощник нужен — хомо сапиенс!
— Бери помощников, но чтобы не раньше!

Дело не в компиляции а в статической типизации.

Есть мнение(возможно, неверное), что динамическая типизация для высокоуровневых языков - уровень 60-ых годов, а уже кагбэ другой век на дворе. Но в любом случае, говорить, что статическая типизация - корень проблемы медленной разработки, - признак недалекости.

При наличии мозгов - да. На R например посмотри.

R - нечто узкоспециализированное.

Дело не в компиляции а в статической типизации.

А она ничем не мешает, наоборот, не надо гадать с каким типом программа выполнится.

Что-то я читал здесь про часы компиляции, если не дни.. Так же отладка в интерпретируемых языках проще, а сообщения об ошибках информативнее. Меньше шансов «отстрелить себе ногу».

уровень 60-ых годов, а уже кагбэ другой век на дворе.

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

А она ничем не мешает, наоборот, не надо гадать с каким типом программа выполнится.

Особенно при работе с указателями

У нас двоичные порядки.

Ну мы же говорим о значительном отличии (вроде)..

Ты видел, к примеру, Go? У него синтаксис полаконичнее, чем у JS.

Дело же не только в этом, так же важно отсутствие компиляции, рантайм оптимизации, плюс, я бы хотел, что бы виртуальная машина обладала какими-то дополнительными фичами, брала на себя кластеризацию, например, или обеспечивала коммуникацию между запущенными приложениями, как maglev ruby. Это просто нечто более функциональное нежели машинный код.

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

Плюсопроблемы.

Так же отладка в интерпретируемых языках проще

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

Меньше шансов «отстрелить себе ногу».

Особенно если выполнять программу на интерпретаторе другой версии или с другими патчами.

R - нечто узкоспециализированное.

зато хорошая иллюстрация по-настоящему высокоуровневого языка. Хотя многие фичи R доступны и в пайтоне, например построчный ввод команд с немедленным выполнением (такой шелл своеобразный).

После этого камента бросил читать тред: тема раскрыта.

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

ты в блокноте разрабатываешь? Подсветка синтаксиса есть даже в kwrite. А специализированные редакторы по табу дополняют имена команд и переменных и выводят справку при необходимости (в том числе список аргументов функции и дефолтные значения).

так же важно отсутствие компиляции

go run выполняется не дольше запуска педона.

рантайм оптимизации

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

брала на себя кластеризацию, например

Ну этим из более-менее мейнстримного может похвастаться лишь эрланг. Зато Go (в отличие от питонов и жабаскриптов) нормально умеет в многопоточность и многопроцессорность.

имитировать запуск
А в компилируемом языке такие ошибки вылезут на этапе пробной компиляции

Это типа хорошо? Запуск интерпретируемой программы, он, какбы моментальный..

Особенно если выполнять программу на интерпретаторе другой версии или с другими патчами.

42

ты в блокноте разрабатываешь? Подсветка синтаксиса есть даже в kwrite.

Иногда использую и kwrite, но ты не поверишь, ему что Writeln что Writern - фиолетово а ещё надо напейсать имена функций без ошибок.

Хотя многие фичи R доступны и в пайтоне, например построчный ввод команд с немедленным выполнением (такой шелл своеобразный).

Это называется REPL и есть ну вообще для чего угодно. Даже башик можно таковым считать.

Запуск интерпретируемой программы, он, какбы моментальный..

А что, где-то есть настоящие интерпретаторы? Питон — байткодовая vm, жабаскрипты во всяких V8 — JIT-компиляция.

И у go запуск тоже моментальный, go run ведь.

Ну этим из более-менее мейнстримного

Я говорю в общем, а не конкретно.

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

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

Это типа хорошо?

Ага.

Запуск интерпретируемой программы, он, какбы моментальный..

Начало запуска да а нужная строчка кода по условию может выполняться раз в месяц, и что ждать столько времени?

Особенно если выполнять программу на интерпретаторе другой версии или с другими патчами.

42

Что за сорок два? Ставил питоновый yum в калькулейте и насмотрелся на глюки скриптоты.

Я просто оставлю простенький пример-сравнение:

http = require('http')
Buffer = require('buffer').Buffer;
n = 1024*1024;
b = new Buffer(n);
for (var i = 0; i < n; i++) b[i] = 100;

http.createServer(function (req, res) {
  res.writeHead(200);
  res.end(b);
}).listen(8000);

JS — тоска, безысходность, унылье и страх.

package main

import "net/http"

func main() {
    bytes := make([]byte, 1024*1024)
    for i := 0; i < len(bytes); i++ {
        bytes[i] = 100
    }

    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write(bytes)
    })
    http.ListenAndServe(":8000", nil)
}

Go — процветание, радость, твёрдый контроль над типами данных и уверенность в завтрашнем дне.

Особенно при работе с указателями

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

Я немного не про то. Подобные рантайм оптимизации — костыли, возникающие из-за динамической типизации.

пистолет для стрельбы в ногу

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

http://en.wikipedia.org/wiki/Pattern_matching

Почитал бы, прежде чем позориться.

костыли, возникающие из-за динамической типизации.

я считаю это высшей магией, облегчающей жизнь)

Надо просто случайно крякнуть не уткой

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

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

Для меня чем больше автоматизации - тем лучше.

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

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

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

Была еще одна интересная идея — http://phoenix.labri.fr/publications/papers/osdi00-merillon.pdf — правда что-то не видно чтобы использовалось...

Плакал, плакал, в итоге собрался решил что guile лучше всех. /facepalm

Я понимаю тебя, но считаю иначе. Для проверки есть тесты в конце-концов.

ну это же ппц. Тесты часто не покрывают весь код. Тесты нужно написать. И все равно уверенности в отсутствии ошибки нет.

Статическая типизация полностью исключает некоторые виды ошибок.

Статическая типизация полностью исключает некоторые виды ошибок.

Только в реальности доля таких ошибок очень низкая.

Только в реальности доля таких ошибок очень низкая.

Зависит от языка. Я бы сказал, что в хаскеле доля таких ошибок много больше половины. Даже как-то привык уже, что если компилируется, то работает правильно.

В NeXT использовали динамически типизируемый ObjC для драйверов, и таки уже в OS X от марша по граблям было решено отказаться.

Rust

Так речь-то вроде шла про динамически типизирвоанные языки, не?

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

Исправлять баги и улучшать производительность - ненужно?

скорость разработки важнее (или как минимум не менее важна) скорости выполнения. Компилируемые языки - это вообще вчерашний век.

Расскажи это чувакам из Valve, ага.

Показателем будут стоны о том, что в коде невозможно разобраться, а coffee-таки улучшает ситуацию.

Будут-будут. JS просто кошмарен.

Ваще, всё критичное к производительности надо писать на языке уровня C++, только более вменяемом. Вот если Rust когда-нибудь допилят, будет торт.

А всё некритичное - на языках уровня Ruby.

Мм.. т.е. ты еще и против тестирования.. интересно.. Тогда логично, что тебе нужны инструменты уменьшающие вероятность ошибки, но, на мой взгляд, это слабый инструмент, как я уже говорил, параметры можно перепутать и не нарушив тип. Какой тип ошибок статическая типизация _полностью_ исключает? Это не говоря о том, что может быть передан массив, или хэш.

JS просто кошмарен.

Думаю, js допилят с большей вероятностью..

В чем смысл статической типизации в интерпретируемых языках?

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

Статическая типизация полностью исключает некоторые виды ошибок.

Только в реальности доля таких ошибок очень низкая.

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

Была еще одна интересная идея — http://phoenix.labri.fr/publications/papers/osdi00-merillon.pdf

Это всё-таки не язык программирования.

Ага. Вот именно...

... Вот тут Вы абсолютно правы. Именно по этой причине (это одна из причин), то что называется «системным программированием» раньше плотненько сидело на асме. С выходом в свет С все вздохнули с облегчением, переползли на С и считают что для задач, которые при программировании модулей приходится решать, С вполне довольно. Я вот уже лет 10-15 слышу угрозы «переписать все» на плюсах... Жду когда эти угрозы станут реальностью, поглядывая на могилку Symbian (пожалуй, единственной распространенной массово ОС, ядро которой было написано на С++).

И, Вы не поверите, но даже есть люди, которым нравится С. Авторы таких тулкитов как Gnome/Gtk, например. Я отдаю себе отчет в том, что есть люди, ненавидящие С. Да и Господь с ними. «Неосиляторы» не интересны принципиально.

/* Оно, наверное можно по-растекаться мысью по древу, привести в пример еще абсолютно трезвых парадигм, методологий и т.д. и т.п., но мне это все здорово напоминает этакий... «высокотехнологичный онанизм». А мне простите, писать вот тут надо. */

Гы-гы-гы...

... Вы часом не помните такую группу как «Машина Времени»? Ну, там... Макаревич... Песня у них хорошая есть. Даже две.

В первой слова есть — «Ты можешь ходть как заброшенный сад, а можешь все наголо сбрить. И то и другое я видел не раз. Кого ты хотел удивить?» ;)

Во второй — «Не стоит прогибаться под изменчивый мир. Однажды он прогнется под нас». ;)

Все это (ВСЕ!) уже было и не по одному разу. Но всегда оставались люди, которые... писали эти ваши интерпретаторы, оптимизировали и занимались прочей «фигней» с точки зрения «прикладников». Кстати да. Чем больше именно «прикладников», тем лучше... :))) Наши доходы тем выше. :)))

Отлично! Еще один! ...

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

В ответ, если будет хоть что-нибудь толковое, я обязуюсь объяснить почему я написал tailgunner'у именно то, что написал. Но это может оказаться очень долго.

Итак, вперед. Смелее! :))) Я очень хочу взглянуть на то, как Вы можете применить свои крайне обширные знания на практике. ;)

писали ... оптимизировали

Я же говорил уже: «безумству храбрых поем мы песни». Кто-то должен сделать инструмент, а кто-то должен его использовать.

Но всегда оставались люди

Поразительная близорукость. ИТ индустрия еще только на заре. Да, со временем, людей пишущих интерпретаторы станет меньше, но, пока что интерпретаторы можно по пальцам пересчитать (это тренд!), еще даже компилируемые языки не прекратили появляться. Инструменты на си (пока) нужны, а программы на си (для юзеров) - (уже) нет, вот и вся математика. Например Blender - прекрасный проект, где на си написано на столько мало, на сколько это возможно.

есть люди, которым нравится С. Авторы таких тулкитов как Gnome/Gtk, например

Я бы сказал, что у них к Си нечто более сильное, чем просто «нравится» - это настоящая любовь. Слепая, как ей и положено.

Это называется REPL и есть ну вообще для чего угодно.

Для любого ИНТЕРПРЕТИРУЕМОГО языка. Хочешь подобное сделать для сишечки - придется писать интерпретатор сишечки.

Даже башик можно таковым считать.

А с каких пор башик компилируемый?

Go — процветание, радость, твёрдый контроль над типами данных и уверенность в завтрашнем дне.

Что-то код сильно Паскаль напоминает.

Откуда появился «произвольный код»? На Си-обработчиках прерываний не пишут произвольного кода.

Оттуда, что у нас же теперь Lua и «низкий порог вхождения».