ИЧ
Это сейчас даже у C++ хорошо получается и у Node.js. 🤷♀️
к сожалению, поэтому кресты в приоритете, питон у нас хотят убить, правда выяснилось что с кадрами не так всё просто) мало кто захочет ручки пилить на плюсах из продвинутых юзеров
Size: a a a
2020 March 31
ИЧ
MaxGraey
Без проблем
остаётся дело за малым - пробиться в список разрешенных языков
ИЧ
а если с гошкой сравнивать?
МБ
MaxGraey
gradual typing, LLVM JIT поэтому очень быстрая. Невероятный набор типов, есть даже two folded float points. Ну и мат библиотека вылизана намного лучше питоновской и главное написана на той же Джулии
А они теперь офоциально пишут о gradual typing? Раньше у них было multistage specializing compilation.
M
SM
OOP in Julia is arguably better.
А можно по подробнее? Мне понравилось как в питоне реализовано множественное наследование (с их super()). Про юлию мало знаю
AT
А можно по подробнее? Мне понравилось как в питоне реализовано множественное наследование (с их super()). Про юлию мало знаю
Если Вам нравится как сделано в Питоне, то Julia врядли понравится. 😊
SM
Если Вам нравится как сделано в Питоне, то Julia врядли понравится. 😊
Почему же так?
AT
Почему же так?
Похоже на то, что Вам нравится подход типа more is more, типа https://www.hillelwayne.com/post/negatypes/ а в Julia скорее less is more. Сильно больше ограничений, почти вообще не ООП. 😊
FO
Похоже на то, что Вам нравится подход типа more is more, типа https://www.hillelwayne.com/post/negatypes/ а в Julia скорее less is more. Сильно больше ограничений, почти вообще не ООП. 😊
А мне не понравилось работать с Julia в интерактивном режиме. Слишком далеко надо думать вперед, чтобы не перезапускать REPL для очистки пар имя-переменной:тип-переменной... А вот когда полностью понимаешь, что хочешь сделать и в каких типах - тогда все классно
AT
А мне не понравилось работать с Julia в интерактивном режиме. Слишком далеко надо думать вперед, чтобы не перезапускать REPL для очистки пар имя-переменной:тип-переменной... А вот когда полностью понимаешь, что хочешь сделать и в каких типах - тогда все классно
То ли дело FORTRAN! 😂
FO
То ли дело FORTRAN! 😂
Да. Он просто на компиляции падает в таком случае. :) (Знаю про интерактивный, но не трогал)
Т8
Хороша ли идея разделить в языке, подобном C++ и C, типы указателей на стековые и на хиповые?
например
например
string stackString;
string# stackStringPointer = &stackString;
string* heapStringPointer = new string;E
нужно больше закорючек богу закорючек
PS
Неплохая мысль. Но не хватает информации о том, где сам указатель лежит. Поэтому:
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
#*И я бы еще добавил ? -- когда явно указывать не нужно, пусть компилятор разберется:
*#
?#И для низкоуровневого программирования хорошо бы описать явно и вариант регистровой памяти. Как насчет ` ?
*?
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
A
Т-34 85
Хороша ли идея разделить в языке, подобном C++ и C, типы указателей на стековые и на хиповые?
например
например
string stackString;
string# stackStringPointer = &stackString;
string* heapStringPointer = new string;А если функция принимает указатель и заранее не знает с каким указателем она будет работать? А если компилятор переложит с кучи на стек?
G
Неплохая мысль. Но не хватает информации о том, где сам указатель лежит. Поэтому:
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
#*И я бы еще добавил ? -- когда явно указывать не нужно, пусть компилятор разберется:
*#
?#И для низкоуровневого программирования хорошо бы описать явно и вариант регистровой памяти. Как насчет ` ?
*?
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
Я бы ещё добавил квалификатор
^ - означает закешированное значение, а ^N% - с некоторой вероятностью закешированное значение. Такие образом, ^15%#string - с вероятностью 15% закешированное значение из стека типа данных string.A
Я бы ещё добавил квалификатор
^ - означает закешированное значение, а ^N% - с некоторой вероятностью закешированное значение. Такие образом, ^15%#string - с вероятностью 15% закешированное значение из стека типа данных string.Вы тут смеётесь, а меж тем в gcc есть __builtin_expect_with_probability, в котором указывается вероятность перейти на ветвь.
*а вот указаний для кэширования иногда как раз в языке действительно не хватает
*а вот указаний для кэширования иногда как раз в языке действительно не хватает
VK
Неплохая мысль. Но не хватает информации о том, где сам указатель лежит. Поэтому:
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
#*И я бы еще добавил ? -- когда явно указывать не нужно, пусть компилятор разберется:
*#
?#И для низкоуровневого программирования хорошо бы описать явно и вариант регистровой памяти. Как насчет ` ?
*?
И тогда можно будет компактно описывать такие случаи, как string`#?**
Но главное, чтобы объявление функции в языке использовало слово "fn", без этого ничего не выйдет.
Выглядит слишком hardcoded. Надо ввести пользовательские типы указателей - (OMG#)(WTF?)(LOL!).
PS
Выглядит слишком hardcoded. Надо ввести пользовательские типы указателей - (OMG#)(WTF?)(LOL!).
Это слишком по-хакерски. Респектабельный корпоративный вариант использовал бы стандарт URI.