Один из признаков того, что язык программирования имеет успех, – появление новых языков на его основе. Известным примером является JavaScript. На его базе возникли такие языки, как TypeScript, GorillaScript, Kaffeine, Sweet.js и так далее.
Со временем язык программирования Go, разработанный компанией Google, сможет соперничать с JavaScript по количеству надстроек и диалектов.
Миру уже был явлен Oden – функциональный язык со статической типизацией, разработанный в рамках экосистемы Go. В то же время он создавался как надстройка Go и впитал в себя его лучшие стороны.
А теперь появился новый язык – Have, который имеет все шансы стать усовершенствованной и дополненной версией Go. По крайней мере, так считает его автор – польский разработчик Марцин Врохняк.
Он признает, что пока это хобби-проект, но надеется выйти на серьезный уровень и занять почетное место в экосистеме Go. В своем блоге он рассказал о некоторых особенностях языка и его отличиях от Go.
Во-первых, Have явно отличается форматированием: Go использует фигурные скобки (как в Си):
if a() {
b()
} else {
c()
}Have пошел по пути Python в этом плане:
if a():
b()
else:
c()Еще одно стилевое отличие – способ объявления переменных, структур и интерфейсов.
Объявление структуры и ее метода в Go:
type A struct {
x int
}
func (a A) String() string {
return fmt.Sprintf("x:%d", a.x)
}Врохняк полагает, что такой стиль объявления поможет избежать досадных ошибок:
struct A:
x int
func String() string:
return fmt.Sprintf("x:%d", a.x)interface Reader:
func Read(p []byte) (n int, err error)В Have реализована работа с шаблонами. Разработчики Google не стали добавлять ее в Go из соображений простоты. Тем не менее, Врохняк считает, что это важный и мощный инструмент, который должен присутствовать – must have, как говорится:
struct SampleStruct[T]:
func Method(p T) T:
return pT – имя типа данных.
var a SampleStruct[int], b SampleStruct[string]
var x int = a.Method(1), y string = b.Method("one")Аналогично шаблоны используются в функциях:
func SampleFunc[T](p T) T:
return pНа этом разработчик не остановился и добавил так называемые специализации. В зависимости от типа внутри функции, например, может выполняться та или иная обработка данных. Ветвление осуществляется с помощью ключевого слова «when»:
func SomeFunc():
when int
is int:
print("int is int, who would've thought?")
is string:
print("int is string, better report a compiler error!")Подстановка того или иного типа происходит на этапе компиляции. Врохняк отмечает, что вне контекста шаблонов «when» не имеет практического применения.
func CopyBytes[T, K](src T, dst K):
when T, K
is []byte, implements io.Writer:
# копируем содержимое участка памяти в поток записи
pass
is []byte, []byte:
# копируем содержимое участка памяти в другой участок памяти
pass
implements io.Reader, is []byte:
# копируем содержимое потока чтения в участок памяти
pass
implements io.Reader, io.Writer:
# копируем содержимое потока чтения в поток записи
pass
default:
# делаем что-то по умолчанию
passТак как Have находится на начальном этапе развития, многие проблемы Go в нем не решены. К примеру, реализация обработки ошибок в Go требует бесполезных затрат времени для написания однотипного кода.
У автора Have большие планы, но как всегда, мало времени. В ближайшее время язык будет совершенствоваться. Существенный объем функциональности Go пока не реализован в Have. Этому и будет отдан приоритет в обозримом будущем, отмечает Врохняк.
Вторая по важности задача – обеспечение совместимости с Go: чтобы можно было программировать на Go в проектах, написанных на Have.
Go был разработан внутри компании Google. Первоначальная разработка Go началась в сентябре 2007 года, а его непосредственным проектированием занимались Роберт Гризмер, Роб Пайк и Кен Томпсон. Официально язык был представлен в ноябре 2009 года.
Язык Go разрабатывался как язык системного программирования для создания высокоэффективных программ, работающих на современных распределённых системах и многоядерных процессорах. Он может рассматриваться как попытка создать замену языку Си. По крайней мере, в это верят разработчики Go.
Комментарии (99)
byd
26.09.2016 11:15-2" реализация обработки ошибок в Go требует бесполезных затрат времени для написания однотипного кода" — бесполезных, серьёзно?
Dionis_mgn
26.09.2016 15:00+6Да, серьёзно. Если я вынужден писать одно и то же через каждую строку-две, это — бесполезно. И велико искушение вообще забить на обработку ошибок.
Azoh
26.09.2016 15:00+4Серьезно. Проверять ошибки вместо обработки исключений — это простейший способ бесполезно потратить кучу времени.
Вот нужно открыть файл, прочитать оттуда, записать туда, закрыть файл. Если что-то не смогли, то дальнейшая работа должна остановиться. Отсюда получаем, что нужно 4 проверки. С исключениями это все превращается в один перехватчик.
Более того, в большей части приложений перехватчики нужны в основном на границах модулей, что позволяет избежать написания огромной кучи кода. А, как известно, лучший вид кода — это отсутствующий код. Его не нужно поддерживать, там нет багов, он даже не требует времени на написание.
Более того, современные способы работы с исключениями не создают дополнительного оверхеда, в отличии от проверки ошибок.
avost
26.09.2016 18:02Однотипного? Ну, да, вместо того чтобы писать однотипный код можно было потратить время с бОльшей пользой.
impwx
26.09.2016 11:26+1То, что автор называет генериками, на самом деле перегрузка функций (пример с
CopyBytesиз статьи) и макрошаблоны (пример сMaxс сайта). Очень интересно, как нужно будет обращаться к этим функциям из Go.
iCpu
26.09.2016 11:28+10Жило было 14 конкурирующих языков программирования…
snuk182
26.09.2016 12:49+18а надо было сразу с дженериками создавать, а не петь мантры разработчикам «вам это не нужно»…
iCpu
26.09.2016 12:56+1Я не до конца в теме (я вообще не в теме), это что-то вроде расширяемого синтаксиса Лиспа, который позволяет плодить свои диалекты Лиспа даже не требуя пересборки исходников Лиспа?
creker
26.09.2016 13:43-1Никто не пел. Дженерики были бы, если бы кто-то предоставил подобающее решение, которое устроит команду разработчиков. Есть идеи, исследования, но пока на этом все. Все существующие реализации отвергли по теме или иным причинам.
snuk182
26.09.2016 13:48+3ИМХО, это как раз тот случай, когда не совсем удачное решение лучше, чем нет решения вовсе.
creker
26.09.2016 13:49Поскольку с этим «не совсем удачным» решением пришлось бы жить годы и тащить всю жизнь языка, то наверное нет. Пора уже перестать идти на поводу у тех, кому вот прямо надо и все тут. Отлично живется без дженериков языку и не сильно его просит аудитория. Будет — скажут спасибо. Не будет — ну и ладно.
TheShock
26.09.2016 16:09+2Мне вот кажутся идеальными Дженерики в СиШарпе. Вот правда, пока дошел до него — все дженерики мне казались не очень. Например в той же Джаве из-за type erasure. В СиШарпе же они работают просто так как должны, очень мощные и гибкие. И чем они плохи для Гоу?
snuk182
26.09.2016 16:26+1На Java как образец дженериков не смотрите.
Точнее, смотрите, как на образец «что будет, если их даже не планировать, но потом в какой-то момент осознать, что так жить дальше нельзя». Это сейчас настолько повально распространенная вещь для статически типизированных языков, что вполне должна входить в общую образовательную базу.
По теме: Proposal, FAQ, RFC
Показательно, что RFC по нему открыли только в апреле этого года.TheShock
26.09.2016 16:55На Java как образец дженериков не смотрите.
Так я ж и говорю, что там отвратительные =) Хороши в C#, там тоже добавили не сразу, но поступили мудро, что забили на первые версии и теперь имеют нормальные дженерики.
Просто не получится ли с Гоу так же как с Джавой — вставят какую-то фигню через пару лет типа type erasure и потом все плеваться будут, а они только плечами двигать, мол обратная совместимость, раньше думать надо было?snuk182
26.09.2016 17:06Если верить FAQ — поддержка потенциальной возможности generics есть изначально, они решили сначала решить вопросы стабильности и производительности рантайма.
creker
27.09.2016 11:58-1Дженерики если и будут, то только в Go2, на что гарантии совместимости не будут распространяться. Go1 позволяет добавлять только то, что не сломает текущий код, что позволяет вносить минимальные изменения в спецификацию.
creker
26.09.2016 16:37https://github.com/golang/go/issues/15292 тут вот обсуждение и ссылки на отвергнутые предложения. Я не сильно вдавался, но на поверхности выходит, что Go довольно уникальный язык и на него плохо ложатся обычные дженерик как у всех (в частности, плохо ложатся на интерфейсы), а некоторые реализации просто не хочется использовать ввиду их убогости. Вроде C++, что само собой мало кому хочется видеть. Конечно можно было давно что-то добавить, но весь цикл разработки языка прямая противоположность такому подходу — пока что-то не понравится всей команде, то этого не будет в языке. И, надо сказать, для них это отлично сработало.
Собственно, я к этой теме потерял интересно давно и совершенно не жалею, что этого нет в языке. Больше беспокоят всякие мелочи вроде невозможности использовать := для одновременного объявления переменной и присвоения значения полю структуры. Приходится заводить заранее переменную и использовать обычный =. Мелочь, а встречается намного чаще, чем необходимость в дженериках.TheShock
26.09.2016 17:11+1Я не сильно вдавался, но на поверхности выходит, что Go довольно уникальный язык и на него плохо ложатся обычные дженерик как у всех
Я вот несколько раз то обуждение прочитал. Может потому что английский у меня не идеален, но я так толком и не понял, почему им не нравятся Дженерики из c#. Про С++ есть прямо: «The problem with C++ generics (without concepts) is that the generic code is the specification of the generic type. That's what creates the incomprehensible error messages. Generic code should not be the specification of a generic type». К сожалению я не совсем понял, т.к. не знаю С++.
Про Джаву тоже: «unlike in Java, so you can find out types at run time. You can also instantiate on primitive types, and you don't get implicit boxing in the places you really don't want it: arrays of T where T is a primitive». Но вот в C# нету такой проблемы.
Мне особенно «нравятся» вот такие аргументы: «One key aspect of Go is that when you write a Go program, most of what you write is code. This is different from C++ and Java, where much more of what you write is types. Genus seems to be mostly about types: you write constraints and models, rather than code». Больше подходит для политического лозунга, а не технического обсуждения.
«Мелочь, а встречается намного чаще, чем необходимость в дженериках» мне, все-таки, кажется, что необходимость в них может варьироваться зависимо от домена.MacIn
26.09.2016 18:19+2The problem with C++ generics (without concepts) is that the generic code is the specification of the generic type. That's what creates the incomprehensible error messages. Generic code should not be the specification of a generic type
Тут речь идет о том, что если мы используем какой-то шаблон, ошибка выявится глубоко внутри библиотеки, там где она попробует воспользоваться заданным при специализации типом. Они предлагают определять сразу, подходит ли какой-то тип для специализации шаблона, или нет.
Sirikid
27.09.2016 00:24+2C#-дженерики используют кодогенерацию в рантайме, у Go в рантайме только GC и многие считают что это уже слишком много.
Razaz
27.09.2016 12:01Считают. Но если даже GC слишком много, то зачем им Go? о_0 Понятно что там есть плюсы свои. Но всетаки.
creker
27.09.2016 12:14Я не видел ничего про GC, но написано прямо черным по белому — никакой кодогенерации в рантайме. C# поэтому даже вообще не обсуждается — такой подход по определению не подходит
Source
26.09.2016 14:49+7Дженерики были бы, если бы кто-то предоставил подобающее решение, которое устроит команду разработчиков.
Хм, интересная позиция… Разве команда разработчиков не в состоянии разработать решение, которое её же и устроит?
creker
26.09.2016 14:54Дженерики они рассматривали и все реализации их так или иначе не устроили. Некоторые серьезные проблемы исходят из самого языка, а именно — интерфейсов. Поскольку это Open Source проект, то дверь оставили открытой https://github.com/golang/go/issues/15292
Source
26.09.2016 15:06+7Ну, я не очень в теме как выстроен процесс разработки Go. Но со стороны это выглядит примерно так: "Мы тут накосячили с архитектурой языка так, что даже сами не можем придумать решение, но у нас Open Source, так что давайте теперь как-нибудь силами сообщества вопрос порешайте, а мы рассмотрим ваши предложения, может быть.."
creker
26.09.2016 15:20Нет, это выглядит не так. Мы придумали язык такой, какой он есть (интерфейсы самое главное преимущество языка и никакое отсутствие дженериков этому никак не мешает), а вы тут хотите сверху прикрутить что-то из абсолютно других языков, просто потому что хочется как у них. Все текущие реализации так или иначе криво работают, либо вообще не совместимы с языком. Это не проблема языка, а проблемы этих реализаций. Авторы потратили на это время, не нашли. Более смысла тратить на не очень то нужную языку фичу нет. У нас Open Source, поэтому если кто-то сможет, то пожалуйста. В данный момент есть намного более важные вещи, которые стоит добавить в язык и его библиотеку. Например, нормальная работа с многомерными массивами и вот сейчас бурно обсуждаются type alias'ы.
Sirikid
27.09.2016 04:41> сейчас бурно обсуждаются type alias'ы
А можно подробнее? Я просто думал обычное объявление типа это и есть type alias.creker
27.09.2016 12:12Вот тема https://github.com/golang/go/issues/16339 Внимание, оно огромная и все это сплошной спор. Мне, честно говоря, не особенно нравится самому эта штука и там много споров из-за того, что людям кажется, что Google проталкивает это изменение для себя и не предоставляет нормальной аргументации в пользу. Даже кажется, что поставили перед фактом и просят предоставить аргументы против. Но, в тоже время, во всех остальных языках это есть и вроде живут нормально.
А предложение довольно простое — возможность объявить альтернативное имя для типа/функции/т.д. Что-то вроде
const C => L1.C // for regularity only, same effect as const C = L1.C type T => L1.T // T is an alias for type L1.T var V => L1.V // V is an alias for variable L1.V func F => L1.F // F is an alias for function L1.F
Основной аргумент в пользу — упрощения рефакторинга для больших кодовых баз.Sirikid
27.09.2016 12:45Предложение интересное, (лично мне кажется что) как раз многие языки такой возможности не имеют и это не особо мешает. Насколько понял добавление нового ключевого слова даже не рассматривается т. к. собираются добавить в 1.X релиз?
creker
27.09.2016 12:54Думаю нет. По мне так, => неплохо смотрится. До этого было ->, но уж очень коробило сходство с операцией над каналами, поэтому поменяли.
Про все остальные языки я конечно погорячился, но это есть в Rust и Swift как минимум.Sirikid
27.09.2016 13:02+1В Rust, Swift и вообще эта конструкция связана не с абстрактными типам/константами/переменными/функциями а с импортом, то есть ты импортируешь сущность и можешь её переименовать, это логично. Либо же это type aliases которые работают как сишный typedef (только для типов), я думал что type в Go работает так же, по крайне мере для интерфейсов.
DarkEld3r
27.09.2016 14:48+1В Rust, Swift и вообще эта конструкция связана не с абстрактными типам/константами/переменными/функциями а с импортом
Да ладно?
type MyMegaInt = i32;
typealias AudioSample = UInt16Sirikid
27.09.2016 15:131. Второе предложение как раз про это.
2. Go тоже так умеет.DarkEld3r
27.09.2016 15:24+1Про Go ничего и не говорил. Речь о том, что "синонимы" типам в расте и свифте можно давать независимо от импорта. Или я всё-таки что-то не так понял?
Но всё-таки, если Go так умеет, то можно разжевать в чём же суть предложения, которое обсуждалось выше?
Sirikid
27.09.2016 15:55+1В Go предлагают добавить возможность объявлять псевдонимы не только для типов но и для всего остального (констант, функций, переменных) и в любом месте пакета, при этом из нового синтаксиса будет только оператор (и на этом спасибо).
DarkEld3r
27.09.2016 16:28Теперь понятно, спасибо.
Тем не менее, в расте (насчёт свифта уже не уверен) оно всё равно работает и для импорта и без него.
Sirikid
27.09.2016 16:54~~Ты должен был победить зло, а не присоединиться к нему!~~
То есть виноват, не очень понял этот момент Rust. Но Rust-вариант мне нравится больше, можно хотя бы `use` грепать а не `=>`.
creker
26.09.2016 11:31+4Python синтаксис — нет нет и нет. Тонна ошибок на ровном месте. Особенно с учетом требований Go — отсутствие необходимости писать в IDE или ее подобии (никаких вимов с тонной плагинов) и автоматическое однозначное форматирование любого кода. Один неправильный отступ и до свидания.
В Have реализована работа с шаблонами. Разработчики Google не стали добавлять ее в Go из соображений простоты
Их не стали добавлять из-за отсутствия реализации, которая отвечает требованиям команды разработчиков. Они довольно серьезные и не только из-за капризов разработчиков, но и других конструкций языка, с которыми шаблоны должны быть прекрасно совместимы. Issue на гитхабе открыта для предложений.
реализация обработки ошибок в Go требует бесполезных затрат времени для написания однотипного кода.
Что?
Начинание правильное, но, по-моему, не те вещи он начал исправлять. Больше похоже на очередной проект, в который человек просто добавил все, что ему захотелось из других языков. Лучше было начать с github и открыть все быги с тегом Go2 — там предостаточно отличных идей и предложений, которые довольно не скоро появятся официально, т.к. судьба Go2 пока еще мутная.
iroln
26.09.2016 23:52+9Один неправильный отступ и до свидания
Пишу на Python уже лет 7. За это время видел тонны ошибок в программах из-за динамической природы языка, но ни разу не видел ошибок из-за неправильных отступов. Может хватит уже муссировать этот миф с проблемой indent-based синтаксиса в Python?
mich_ovs
26.09.2016 12:14+4struct A: x int func String() string: return fmt.Sprintf("x:%d", a.x)
Я одно не понял, а откуда тут имя 'a'? Похоже на ошибку копипаста.
В целом, мне нравится новый синтаксис — стало нагляднее.
Warlock_29A
26.09.2016 13:27Возможно и не опечатка, в го по идеи должно было быть написано так:
func (a A) String() string
Тут возможно есть какое то соглашению по тому как генерируются имя переменной, чтобы обращаться к полям структуры.
snuk182
26.09.2016 15:13В оригинале есть упоминание self для указателей. Видимо, naming convension дкйствует только для методов, вызываемых по значению.
What about pointer receivers? They are there, too. You declare them by putting a * before function name. The method receiver is always referred to as self. struct A: counter int func *Inc(): self.counter++
Кстати, странно, что про этот куда более используемый кейс — ни слова.
baka_cirno
26.09.2016 14:33+11Я так понимаю, про ошибки с табуляцией, «характерные для Python», в основном пишут те, кто Python никогда серьезно не использовал. Потому что те, кто работает с ним каждый день, почему-то никогда на это не жалуются.
NeoCode
26.09.2016 14:51Возможно. Но мне идея форматно-несвободного языка как таковая не нравится. На питоне не пишу вообще, но иногда приходится наталкиваться на какие-то экзотические вещи, в которых от случайно поставленного не там пробела или табуляции, или табуляции вместо пробелов что-то ломается и не поймешь где.
euspensky
28.09.2016 11:17+1От «случайно поставленных не там пробелов или табуляций» в 99% случаев программа просто перестает запускаться, и выдает IndentationError, с указанием строки. Поведение в точности как в других языках при случайно и не там поставленных скобочках.
lookid
26.09.2016 14:58+5Я так понимаю, про неудобство есть суп ножкой от стола, в основном пишут те, кто ножкой от стола суп никогда серьезно не ел. Потому что те, кто ест суп ножкой от стола каждый день, почему-то никогда на это не жалуются.
baka_cirno
26.09.2016 15:12+1Не аргумент. Тысячи совершенно неглупых людей уже не первый десяток лет поглощают супы ножками от стола, и чувствуют себя прекрасно.
creker
26.09.2016 15:23-3Вот это как раз не аргумент. Аргумент — это объективный недостаток решения Python в виду генерации невидимых ошибок, которые ломают код в рантайме, просто потому что где-то неправильный отступ. И все аргументы в пользу этого от питонистов сводятся к какой-то идеологической проблеме — не хочу и не буду писать скобки, потому что уже есть отступы. То, что это генерируется только новые проблемы и не решает никаких старых, это как бы не важно. Привыкли — замечательно, но это не показатель успешности решения. Показатель это тот факт, что никто из популярных языков такое решение не принял кроме питона.
NeoCode
26.09.2016 15:35Из популярных — нет, но судя по всему многие изучение программирования начинают с питона и это оказывает неизгладимый отпечаток. Например в Nim ввели такой же синтаксис, еще где-то видел. Возможно это действительно другая парадигма мышления — ну чтоже, пускай будут разные языки, время рассудит. Я для себя решил что в собственном языке программирования никаких невидимых отступов не будет, только старые добрые скобки :)
ufm
26.09.2016 16:45+5Почему питонистам нельзя есть суп ножкой от стола, если куча других людей едят суп ножкой от табуретки и считают что это правильно?
Пример:
if (a == 1) a++; b++;
Это C, если что. Какое количество ошибок в куче программ повылазило только из-за того, что блок может состоять только из одного оператора…Sirikid
27.09.2016 04:49+21. Не забывайте что C написали 40 лет назад.
2. if (a == 1) a++, b++; // Готово :)ufm
27.09.2016 15:28+11. С — да, старый. Но ведь это решение потом потянули везде где только можно. В Rast разве не так-же?
2. это если человек осознанно пишет. А в таком случае и скобки написать можно.
creker
27.09.2016 21:35И к чему это здесь? В Go такое написать нельзя, к чему здесь С? Да, там есть проблема и приходится дисциплинировать себя, чтобы ее максимально избегать. Ровно тоже самое, что питоновская строчка, которая может съехать и изменить логику всего блока кода.
baka_cirno
26.09.2016 19:49+6Дело в том, что проблемы нет. Не генерируются никакие скрытые ошибки, о которых вы пишете. Может, они в вашем представлении должны были бы генерироваться, но не генерируются. Вот такая фигня.
creker
27.09.2016 21:39-1Дело в том, что проблемы нет у вас. Проблема есть у языка и его синтаксиса. Она есть и никуда от заявлений, что у кого-то ее не было, не девается. Совершенно не случайно в современных популярных языках нет этого синтаксиса, а так же нет C синтаксиса, где можно опустить скобки. Go, Rust, Swift не дадут написать условие без скобок, что абсолютно верно.
Bonart
26.09.2016 20:11+1Вы не поверите — в Питоне нет невидимых ошибок из-за отступов. Зато есть одинаковое понимание отступов человеком и компилятором.
Кстати, самый зрячий на ошибки компилятор у хаскеля. При той же отступной грамматике.creker
27.09.2016 21:41-3А где не одинаковое? В языках со скобками отступы понимаются ровно точно так же как и человеком — необязательный символ форматирования кода. Проблема в том, что зачем-то невидимый символ форматирования стал частью синтаксиса и все никак не видно объективных преимуществ в пользу этого. Кругом только неприязнь скобочек и заявления, что никаких ошибок нет и не бывает.
Bonart
28.09.2016 01:13+3Необязательный?
Начните коммитить код без отступов — и команда вас проклянет.
Начните коммитить код с отступами, не согласованными со скобками — и коллеги вас убьют, а суд их оправдает.
А компилятору все равно.
Принимаются стандарты оформления, которые делают несоответствия между скобками и отступами максимально заметными.
Отступные грамматики делают чтение отступов у транслятора таким же, как у человека. Теперь плохое оформление отступами отслеживается раньше, чем код-ревью и вообще автоматически.
Заодно экономится куча строк, ранее занимаемых скобками.
johnnymmc
26.09.2016 15:00+6Один из признаков того, что язык программирования имеет успех, – появление новых языков на его основе. Известным примером является JavaScript. На его базе возникли такие языки, как TypeScript, GorillaScript, Kaffeine, Sweet.js и так далее.
Несколько наивное утверждение. Главная причина появления новых языков «на базе JavaScript» — то, что он встроен в браузеры. Это как говорить о успехе машинных кодов x86 как языка программирования на основе того, что C, C++, Pascal, Haskell, Go и др. компилируются в них. Вторая причина — то, что сам он достаточно неудобен, чтобы многим хотелось как-то его улучшить и/или чем-то его заменить.Azoh
26.09.2016 15:05Так наоборот, все правильно. Язык успешен и захватил зону рынка. Но неудобен для части людей. Но в силу успешности языка им приходится иметь с ним и его экосистемой дело. И они задумываются о том, что нужно создать свой язык, который нацелен на туже экосистему, но который все неприятные части убирает, а приятные добавляет.
А не будь язык успешен, то никто не стал бы даже думать о таких вещах.
Source
26.09.2016 15:01+16Один из признаков того, что язык программирования имеет успех, – появление новых языков на его основе. Известным примером является JavaScript.
Имхо, появление транспилеров — это признак того, что на исходном языке писать жутко неудобно/неприятно/etc., но какие-то другие факторы принуждают к этому. И JavaScript — яркий тому пример.
Своеобразный лайфхак — писать на приятном языке, а генерацию кода на неприятном языке поручить транспилеру. Разве есть другие причины писать транспилер?ufm
26.09.2016 17:06+1Причина писать транспайлер еще может быть в том, что destination language есть подо всё, что шевелится. Как пример, автор NIM совершенно разумно сделал транслятор в C — как следствие он получил возможность компиляции на любую железку, для которой есть C копилятор (т.е. чуть более, чем под любую).
Source
26.09.2016 18:28+1Так я не вижу здесь противоречия. Если автор Nim считал бы С идеальным ЯП, то он не стал бы делать свой язык. Получается, что ему нравятся компиляторы C, но не нравится C как язык.
asdf87
27.09.2016 04:46+1Скорее автору Nim нравятся целевые платформы компиляторов C, а не сам язык и его компиляторы.
denis_g
26.09.2016 23:58-1Первая реакция: Фу!
(Это чисто мое мнение, оно может не / не должно совпадать с мнением большинства)
Sirikid
27.09.2016 04:58Интересное сочетание синтаксиса и статической типизации, из похожих только Haskell, который скорее про науку чем про production, ещё можно вспомнить Eiffel и Occam.
NeoCode практически любой язык сейчас «форматно-несвободен» (привет code style), а тут ещё и два символа экономим :)NeoCode
27.09.2016 08:04code style то я могу сам выбирать. Экономия символов это мелочи. А неприятно то, что при вставке кода из другого источника (даже из другого места этого же файла) в середину существующего кода нарушается не просто красота, а целостность синтаксической структуры. И пока ее не восстановишь — ничего работать не будет. В форматно-свободных языках можно вставить код в любое место и затем просто запустить автоматический форматтер, который все выравняет так как надо. А можно и не выравнивать, пока не будет написан необходимый с точки зрения логики код.
С питоном нужно все делать вручную и каждый раз, потому что там выравнивание — часть синтаксиса языка.Sirikid
27.09.2016 08:31Не всегда. Мелочь, а приятно. Многие IDE и даже текстовые редакторы умеют добавлять отступы в вставляемый код. (А ещё копипаст это плохо, только тсс!)
WinPooh73
27.09.2016 09:43Полное ощущение, что название языка выбиралось специально, чтобы превзойти go в «удобстве» поиска в интернете по ключевому слову.
newmindcore
28.09.2016 11:16+1Ключевое слово для поиска go в интернете – это golang.
WinPooh73
28.09.2016 12:30Да, это все знают. А для поиска игры go — ключевое слово baduk. Маленькие хитрости, неочевидные при первом знакомстве с предметом. Язык C в этом отношении избежал неоднозначности, при всей краткости названия удалось избежать совпадения с часто используемым словом. Впрочем, когда его так назвали, до поисковых машин было ещё пара десятков лет…
Air_Walker
28.09.2016 11:16Я бы еще добавил модульную структуру и импорты как в Python, а то в Go это почему то не добавили
stokker
28.09.2016 11:16Программист должен не скобочки искать или отступы считать, а думать о структуре программы и прочих более общих вещах. Всю черновую работу должны брать на себя IDE. Тогда бы и доводы за или против были бы не с точки зрения «кодерства»…
BratSinot
Лично мне не нравится идея Python'а использовать пробелы и табуляцию заместо скобок. Мне неудобно читать, писать и искать ошибки (теже не закрытые скобки).
bolk
Дело привычки.
Idot
Понятно, что отступы — дисциплинируют, но не все любят когда их заставляют из под палки.
А кроме того, вопрос пишущим на Питоне: когда строка такой длинны, что не помещается на экран, можно ли сделать перенос начинающийся с отступа для удобства чтения? И как такое воспринимает Питон?
iroln
Можно использовать символ
\для переноса строки:Но лучше использовать скобки. В Python можно обвернуть в скобки любое выражение, и тогда его можно переносить на новую строку.
Отступ перенесённой строки в этом случае роли не играет, но обычно придерживаются правил с учётом Style Guide
Idot
Спасибо!
iroln
Гораздо больше людей не любят читать плохо отформатированный код. Для этого принимают Style Guide и придерживаются его. Поэтому разработчику, если он работает над проектом в команде, всё равно придётся придерживаться какого-то стиля форматирования, а не писать как попало.
iroln
Незакрытые скобки должен подсвечивать ваш редактор кода.