Т8
Где не подошёл?
Ну, в платформах java и .net, например
Size: a a a
2020 May 19
G
Потому что Си - не байт-код?
Т8
Потому что Си - не байт-код?
А что ты понимаешь под "байткодом"?
G
Такой ассемблерный язык для ВМ
G
Который очень легко парсить и т.д.
Т8
Который очень легко парсить и т.д.
Типа, больше оверхедов в рантайме даст?
Т8
Перформанс хуже
G
Т-34 85
Типа, больше оверхедов в рантайме даст?
Меньше же
G
Парсить легче
G
По сути там и парсить нечего
Т8
Меньше же
В смысле, си больше бы дал оверхедов
G
Т8
Он более высокоуровневый, его дольше компилировать и интерпретировать
Т8
Понял, соглашусь с тобой
Т8
есть ли какие-нибудь языки с мономорфическими дженериками, которые сохраняют информацию о них в объектные файлы (чтобы можно было дёргать по необходимости)?
VV
Помните, как Майкрософт приравнивали опенсорс к коммунизму, а Линукс к раку? Brad Smith, один из президентов Майкроофта наконец-то признал, что в истории с опенсорсом они были “с неправильной стороны”.
Он там дальше правильно говорит, что хорошо, что жизнь длинная и есть шанс исправить ошибки. https://www.theregister.co.uk/2020/05/15/microsoft_brad_smith_open_source/
Он там дальше правильно говорит, что хорошо, что жизнь длинная и есть шанс исправить ошибки. https://www.theregister.co.uk/2020/05/15/microsoft_brad_smith_open_source/
G
Помните, как Майкрософт приравнивали опенсорс к коммунизму, а Линукс к раку? Brad Smith, один из президентов Майкроофта наконец-то признал, что в истории с опенсорсом они были “с неправильной стороны”.
Он там дальше правильно говорит, что хорошо, что жизнь длинная и есть шанс исправить ошибки. https://www.theregister.co.uk/2020/05/15/microsoft_brad_smith_open_source/
Он там дальше правильно говорит, что хорошо, что жизнь длинная и есть шанс исправить ошибки. https://www.theregister.co.uk/2020/05/15/microsoft_brad_smith_open_source/
👍
DS
Т-34 85
есть ли какие-нибудь языки с мономорфическими дженериками, которые сохраняют информацию о них в объектные файлы (чтобы можно было дёргать по необходимости)?
Вроде бы Свифт что-то делал на эту тему, но это надо смотреть внимательно.
NL
Т-34 85
А, спасибо. Нет, такой вариант не катит, тот, кто будет писать байдинги, охренеет
Ты не поверишь, но таких попыток "улучшить C++" было десятки, если не сотни.
Например, вот https://github.com/felix-lang/felix достойная попытка, да, с двунаправленным мэппингом в C++, но - мёртвая!
Ну например, вот ещё компиляторы:
Chicken: Scheme -> C
Stalin: Scheme -> C (очень агрессивная оптимизация)
Gambit: Scheme -> C
Bigloo: Scheme -> {C, .class, .net}
CLiCC: Common LISP -> {C, .exe}
Jekyll: Jekyll <-> C (обращаю внимание на двустороннюю стрелку)
SmartEiffel: Eiffel -> {C, Java}
MetaC: MetaC -> Intemediate C -> .exe
Java for C++: Java -> C++ (wrappers generator)
OOC: Oberon2 -> {C, .exe}
Я думаю, что костыли - это тупиковый путь, любая граница сред - это потенциальный источник проблем и ошибок. А вдобавок эти границы ещё больше добавляют levels of indirection с соответствующим усложнением кода.
Например, вот https://github.com/felix-lang/felix достойная попытка, да, с двунаправленным мэппингом в C++, но - мёртвая!
Ну например, вот ещё компиляторы:
Chicken: Scheme -> C
Stalin: Scheme -> C (очень агрессивная оптимизация)
Gambit: Scheme -> C
Bigloo: Scheme -> {C, .class, .net}
CLiCC: Common LISP -> {C, .exe}
Jekyll: Jekyll <-> C (обращаю внимание на двустороннюю стрелку)
SmartEiffel: Eiffel -> {C, Java}
MetaC: MetaC -> Intemediate C -> .exe
Java for C++: Java -> C++ (wrappers generator)
OOC: Oberon2 -> {C, .exe}
Я думаю, что костыли - это тупиковый путь, любая граница сред - это потенциальный источник проблем и ошибок. А вдобавок эти границы ещё больше добавляют levels of indirection с соответствующим усложнением кода.
Т8
Ты не поверишь, но таких попыток "улучшить C++" было десятки, если не сотни.
Например, вот https://github.com/felix-lang/felix достойная попытка, да, с двунаправленным мэппингом в C++, но - мёртвая!
Ну например, вот ещё компиляторы:
Chicken: Scheme -> C
Stalin: Scheme -> C (очень агрессивная оптимизация)
Gambit: Scheme -> C
Bigloo: Scheme -> {C, .class, .net}
CLiCC: Common LISP -> {C, .exe}
Jekyll: Jekyll <-> C (обращаю внимание на двустороннюю стрелку)
SmartEiffel: Eiffel -> {C, Java}
MetaC: MetaC -> Intemediate C -> .exe
Java for C++: Java -> C++ (wrappers generator)
OOC: Oberon2 -> {C, .exe}
Я думаю, что костыли - это тупиковый путь, любая граница сред - это потенциальный источник проблем и ошибок. А вдобавок эти границы ещё больше добавляют levels of indirection с соответствующим усложнением кода.
Например, вот https://github.com/felix-lang/felix достойная попытка, да, с двунаправленным мэппингом в C++, но - мёртвая!
Ну например, вот ещё компиляторы:
Chicken: Scheme -> C
Stalin: Scheme -> C (очень агрессивная оптимизация)
Gambit: Scheme -> C
Bigloo: Scheme -> {C, .class, .net}
CLiCC: Common LISP -> {C, .exe}
Jekyll: Jekyll <-> C (обращаю внимание на двустороннюю стрелку)
SmartEiffel: Eiffel -> {C, Java}
MetaC: MetaC -> Intemediate C -> .exe
Java for C++: Java -> C++ (wrappers generator)
OOC: Oberon2 -> {C, .exe}
Я думаю, что костыли - это тупиковый путь, любая граница сред - это потенциальный источник проблем и ошибок. А вдобавок эти границы ещё больше добавляют levels of indirection с соответствующим усложнением кода.
о, спасибо за ссылки! Идея в том, чтобы не столько улучшить Си (хотя и это тоже), сколько дать сишный аби на все фичи языка. И тогда любая либа где угодно заведётся без бубна (если конечный язык понимает Си, разумеется). А улучшает Си и Раст, но этого мало