Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
Вы, вне всякого сомнения, правы. Люди, которым не хватает воображения и усидчивости, чтобы сменить парадигму мышления — не очень хорошие программисты… в основном. Но, однако же, есть и другая сторона вопроса. По моему убеждению, программист — это не тот человек, который пишет команды на странном тарабарском языке. Программист — это человек, решающий задачи с помощью компьютера. Это определение, конечно, можно оспорить, указав на то, что любой человек, пользующийся компьютером, решает на нем какие-то задачи. В таком случае, уточним определение: программист — это человек, решающий уникальные задачи. Когда перед вами стоит задача написать с помощью компьютера текст, вы не программист, потому что каждая секретарша пишет тексты. Но если вам надо придумать и реализовать, как подсветить в текстовом редакторе ключевые слова, вы становитесь программистом (во всяком случае если предположить, что данную задачу никто не решал до вас).
Я сам люблю писать команды. Я люблю это делать с самого детства, с тех пор как увидел Quick Basic. И в каком-то смысле этот язык был гениален — я ведь смог его понять в девять лет почти без посторонней помощи! Однако я отдаю себе отчет в том, что деятельность во имя самой деятельности — игра, а не работа. В программиста очень увлекательно поиграть. И иногда эти игры даже становятся успешным бизнесом. Но это всё не имеет отношения к настоящему делу — решению задач.
Когда человек с прагматическим умом видит новый ЯП, он задает себе вопрос, для чего этот язык ему может понадобиться. То есть он примеряет язык к своим интересам и целям. И зачастую на этом этапе всё и рушится. Человек, для которого нет интереса в том, чтобы просто выучить новый язык, а есть интерес, чтобы овладеть новым инструментом, а затем сразу применять его для решения задачи, будет искать в новом инструменте привычные механизмы. Это естественно и правильно. Потому что в противном случае ему снова придется притвориться, что ему 9 лет и он впервые увидел IDE. Перестал ли он быть программистом лишь из-за того, что у него нет интереса к освоению нового языка? Я не думаю, что перестал. Как не перестал мечник быть воином, отказавшись стрелять из лука.
Простите за пространность изложения. Основная мысль такова: люди, которые любят писать команды — не программисты. Программисты, как я написал выше, — это люди, которые решают с помощью команд задачи.
А в чем вы действительно глубоко правы — так это в том, что люди, которые бегут от уникальной проблемы, которая не решается в одну строчку — не программисты, в том же смысле, в котором человек, не видящий себя кем-то другим — не актёр. Потому что ценно лишь решение такой задачи, которую впервые решили вы. Или хотя бы если ваше решение рациональнее и удобнее, чем решение предшественников.
Я сам люблю писать команды. Я люблю это делать с самого детства, с тех пор как увидел Quick Basic. И в каком-то смысле этот язык был гениален — я ведь смог его понять в девять лет почти без посторонней помощи! Однако я отдаю себе отчет в том, что деятельность во имя самой деятельности — игра, а не работа. В программиста очень увлекательно поиграть. И иногда эти игры даже становятся успешным бизнесом. Но это всё не имеет отношения к настоящему делу — решению задач.
Когда человек с прагматическим умом видит новый ЯП, он задает себе вопрос, для чего этот язык ему может понадобиться. То есть он примеряет язык к своим интересам и целям. И зачастую на этом этапе всё и рушится. Человек, для которого нет интереса в том, чтобы просто выучить новый язык, а есть интерес, чтобы овладеть новым инструментом, а затем сразу применять его для решения задачи, будет искать в новом инструменте привычные механизмы. Это естественно и правильно. Потому что в противном случае ему снова придется притвориться, что ему 9 лет и он впервые увидел IDE. Перестал ли он быть программистом лишь из-за того, что у него нет интереса к освоению нового языка? Я не думаю, что перестал. Как не перестал мечник быть воином, отказавшись стрелять из лука.
Простите за пространность изложения. Основная мысль такова: люди, которые любят писать команды — не программисты. Программисты, как я написал выше, — это люди, которые решают с помощью команд задачи.
А в чем вы действительно глубоко правы — так это в том, что люди, которые бегут от уникальной проблемы, которая не решается в одну строчку — не программисты, в том же смысле, в котором человек, не видящий себя кем-то другим — не актёр. Потому что ценно лишь решение такой задачи, которую впервые решили вы. Или хотя бы если ваше решение рациональнее и удобнее, чем решение предшественников.
Попытаюсь уточнить и обощить. Программист — это человек, который позволяет компьютеру служить для выполнения всё более новых и сложных задач и убыстряя выполнение старых :).
Вы тоже конечно правы, но непонимание как применить новый ЯП к своей работе тоже не является критерием истинности, согласитесь. Это все шоры, в какой-то степени узость мышления. Все потому что нам сложно оценить старые проблемы с новой стороны.
Вот вспомните, показательную как мне кажется, историю с XmlHttpRequest. Не ЯП, но все же история чем-то напоминает. Он был придуман и реализован в Microsoft на заре гегемонии, wiki утверждает что в IE5. И несколько лет не был вообще никому не нужен. Ну есть и есть, и реализован за это время был уже во всех браузерах, а все равно толком никто не пользовался. Пока Google не сделал с его помощью карты, а потом и gmail с динамическим интерфейсом. И тут вдруг все поняли что это не просто новый асинхронный способ выстрелить себе в ногу, а вполне себе работоспособный инструмент, который способен решать свой спектр задач. Не «убийца XXX», а просто новый инструмент, дающий новые возможности и в некоторых случаях экономящий кучу времени.
Вот вспомните, показательную как мне кажется, историю с XmlHttpRequest. Не ЯП, но все же история чем-то напоминает. Он был придуман и реализован в Microsoft на заре гегемонии, wiki утверждает что в IE5. И несколько лет не был вообще никому не нужен. Ну есть и есть, и реализован за это время был уже во всех браузерах, а все равно толком никто не пользовался. Пока Google не сделал с его помощью карты, а потом и gmail с динамическим интерфейсом. И тут вдруг все поняли что это не просто новый асинхронный способ выстрелить себе в ногу, а вполне себе работоспособный инструмент, который способен решать свой спектр задач. Не «убийца XXX», а просто новый инструмент, дающий новые возможности и в некоторых случаях экономящий кучу времени.
Возможно, я как-то неправильно высказался, но я считал, я пытался обобщить высказывание оратора и комментатора, что в реалиях компьютерной эры «программист» — кто создает и решает новые задачи. В том числе используя новые (и другие) языки программирования. Я сам лично давно и прочно увяз в ассемблере и мне очень сложно перейти на что-то новое и более технологичное, но людей, которые постоянно ищут что-о новое, и не устают это делать раз за разом — я только уважаю…
Тогда просто никто не делал веб приложений. Браузеры были тормозными, компы медленными, а веб состоял из страниц, представляющих информацию с очень слабыми возможностями её создания. И это всё должно было хорошо индексироваться и работать одинаково хорошо во всех браузерах, которые реализовывали тогдашние стандарты одинаково плохо.
И это не у любителей дженериков воображения не хватает, а скорее у тех, кто считает их чем-то сложным и не понятным, а потому не нужным в языке :-)
И это не у любителей дженериков воображения не хватает, а скорее у тех, кто считает их чем-то сложным и не понятным, а потому не нужным в языке :-)
Как всегда, в таких статьях не хватает кода, который бы подтверждал наличие воображения у автора.
Вам, видимо, просто неизвестно это имя (что, вообще-то, странно).
Посмотрел в википедии. Большинство проектов, по которым он известен (кроме UTF-8), меня интересуют очень условно. Поэтому не вижу в этом ничего удивительного. И как всегда, я предпочел бы смотреть на примеры кода, нежели на абстрактные рассуждения, по сути не несущие никакого смысла.
Просто интересно услышать минусующих карму. Этот человек так много значит в вашей жизни, что любой, кто его не знает, автоматически вызывает неприязнь?
Да, автоматически. Требовать у соавтора The Practice of Programming (ну и самого Go, если на то пошло) код, подтверждающий наличие воображения… ну, да, похоже, вы обычный современный выпускник чего-нибудь, не знающий, кто такой Пайк, что такое TPP, не идущий дальше буквального кода, но своим невежеством даже немножко гордится, похоже.
Хм… Кто как не автор должен бы в первую очередь делиться своим воображением с окружающими… А без кода вся статья выглядит как просьба автора не ругать язык. Ну и какой в этом смысл?
И кстати заметьте. Я знаю о Go почти с самого момента его появления и в целом отношусь к нему положительно (и это не изменится из-за минусов тут :)). А всё потому, что более важным считаю знать о достижениях, которые, как правило, заслуга группы людей, а не о тех, кто проставлен в титрах к этим достижениям, если только мне не приходится общаться лично с этими людьми. А общаться мне в сообществе Go особо не приходилось, т.к. пока только изучаю возможности его применения на практике.
И знаете, я вот изучаю scala, но узнал кто такой Одерски, только после того, как прочитал большую часть туториалов на сайте, пару месяцев повисел в гугл-группе и начал читать его книги. И даже после этого, я не делаю из него культ и понимаю, что он более менее обычный человек, допускающий ошибки и имеющий недостаток воображения. И один из примеров в том, что он спроектировал scala без поддержки продолжений. Однако ему хватило смелости и интелекта признать, что это была недоработка.
И да, я обычный выпускник какого-то однозначно неплохого ВУЗА, не видящий достижения в том, что вы можете по памяти перечислить разработчиков языка, которым (полагаю) интересуетесь гораздо активнее меня.
Вообще конечно не ожидал тут нарваться на секту свидетелей GO-вы. Полагаю, что уже не важно, что я тут пишу, слив всё равно продолжится. За сим откланиваюсь и оставляю вас с чувством собственного превосходства.
И кстати заметьте. Я знаю о Go почти с самого момента его появления и в целом отношусь к нему положительно (и это не изменится из-за минусов тут :)). А всё потому, что более важным считаю знать о достижениях, которые, как правило, заслуга группы людей, а не о тех, кто проставлен в титрах к этим достижениям, если только мне не приходится общаться лично с этими людьми. А общаться мне в сообществе Go особо не приходилось, т.к. пока только изучаю возможности его применения на практике.
И знаете, я вот изучаю scala, но узнал кто такой Одерски, только после того, как прочитал большую часть туториалов на сайте, пару месяцев повисел в гугл-группе и начал читать его книги. И даже после этого, я не делаю из него культ и понимаю, что он более менее обычный человек, допускающий ошибки и имеющий недостаток воображения. И один из примеров в том, что он спроектировал scala без поддержки продолжений. Однако ему хватило смелости и интелекта признать, что это была недоработка.
И да, я обычный выпускник какого-то однозначно неплохого ВУЗА, не видящий достижения в том, что вы можете по памяти перечислить разработчиков языка, которым (полагаю) интересуетесь гораздо активнее меня.
Вообще конечно не ожидал тут нарваться на секту свидетелей GO-вы. Полагаю, что уже не важно, что я тут пишу, слив всё равно продолжится. За сим откланиваюсь и оставляю вас с чувством собственного превосходства.
Вы даже не поняли, что речь в целом и не про Go, собсно. :( И даже не про культ. А про банальное желание специалиста узнавать о своей специальности (историю, культуру, людей, достижения, всё такое) дальше кода.
Возможно я не понял, что вы не про Go и в целом может даже не про программирование, потому что в вашем комментарии не то, что вы подумали, а то что в итоге написали? Я, например, не вижу всю глубину черного квадрата. И к чему это, если я про вполне конкретные вещи пищу, связанные с программированием? Автор статьи также пишет достаточно конкретные вещи, связанные с программированием.
А что касается культуры и истории, то у нас наверно несколько разное их понимание. Для меня история в IT — это понимание, откуда свои названия получили тип boolean и язык haskell, как на свет появилась быстрая сортировка и даже анекдот про то, почему Вирт не хотел возвращаться в Италию. Для вас же, похоже — это знание того, что последние 4 года делал автор, т.е. как раз всю историю языка. А культура — это употребление сокращенных англицизмов там, где вполне можно написать и по-русски.
А что касается культуры и истории, то у нас наверно несколько разное их понимание. Для меня история в IT — это понимание, откуда свои названия получили тип boolean и язык haskell, как на свет появилась быстрая сортировка и даже анекдот про то, почему Вирт не хотел возвращаться в Италию. Для вас же, похоже — это знание того, что последние 4 года делал автор, т.е. как раз всю историю языка. А культура — это употребление сокращенных англицизмов там, где вполне можно написать и по-русски.
Просто если вы не можете процитировать речь Ленина на Пленуме Московского Совета 20 ноября 1922 г., то вы не философ. Кстати, это не зависит от того, прав ли был Ленин, или нет.
Сечас, мейнстрим: Программисты, потратившие пол жизни на изучение С++, берут шарп, и кодят в нем в С++ стиле, попутно бурча, об отсутсвии деструкторов и шаблонов.
Я долго пытался отучить товарища от функций и спагетти ради объектов и методов, не очень получалось.
Вы путаете C++ и C.
Вы не поверите: объекты и методы сами по себе не панацея. Процедурный подход, о котором вы говорите с пренебрежением, поддерживать иногда проще, чем мешанину спагетти, разнесённой по тысяче классов.
Всё-таки программирование это искусство. ООП, призванное своим создателем (Аланом Кеем) уменьшать сложность, надо ещё «уметь готовить», в том числе должна быть безупречна поддержка объектов и самим языком: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++» :)
Всё-таки программирование это искусство. ООП, призванное своим создателем (Аланом Кеем) уменьшать сложность, надо ещё «уметь готовить», в том числе должна быть безупречна поддержка объектов и самим языком: «Я придумал термин „объектно-ориентированный“, и я уверяю вас, что не имел в виду C++» :)
В C# нет деструкторов?
Не совсем деструкторы — есть финализаторы.
Проблема не в том, есть они, или их там нет. Проблема в том, что вопрос ставится некорректно. Код на C# не подразумевает, что разработчик заботится о ручном управлении памяти — если у вас эта проблема стоит остро, значит скорее всего вы просто неверно ставите задачу, или для ее решения вы выбрали неправильный язык. Для низкоуровневого программирования, где надо считать каждый байт, C# не предназначен и ругать его за нерациональное расходование ресурсов — глупо. Берите C или (если задача сложная) C++.
А финализаторы, по моему опыту, используются только в тех проектах, в которых задействованы слабые ссылки. А это — далеко не всегда. Но разработчик, привыкший в C++ писать деструктор почти каждому классу и точно знать, когда этот деструктор вызывается, приходит в ужас как от сборщика мусора вообще, так и от его недетерминированного поведения в частности.
А финализаторы, по моему опыту, используются только в тех проектах, в которых задействованы слабые ссылки. А это — далеко не всегда. Но разработчик, привыкший в C++ писать деструктор почти каждому классу и точно знать, когда этот деструктор вызывается, приходит в ужас как от сборщика мусора вообще, так и от его недетерминированного поведения в частности.
Я почему-то всегда считал, что в C# деструктор зачастую используется для освобождения неуправляемых ресурсов.
И это — одна из основных ошибок, которые делают разработчики на C++, переходя на C#, простите меня за высокомерие. Для освобождения неуправляемых ресурсов необходим детерминированный механизм. Финализатор не подойдет. Вы просто не будете знать, в какой момент ваш ресурс освобожден, вы даже не сможете проконтролировать, в каком порядке освобождаются ресурсы. Поэтому в C# есть даже специальный интерфейс, созданный для объектов, хранящих внутри неуправляемые ресурсы — IDisposable. А вот тут люди обсуждают, как им правильно пользоваться.
Гдядишь — пригодится кому:
public class Sample : IDisposable
{
private object _unmanagedResource;
private bool _disposed;
#region IDisposable
private void Dispose(bool disposing)
{
if (!_disposed)
{
if (disposing)
{
// Dispose managed resources
if (_unmanagedResource != null)
{
((IDisposable) _unmanagedResource).Dispose();
}
}
// Dispose unmanaged resources
_disposed = true;
}
}
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
~ContentReader()
{
Dispose(false);
}
#endregion IDisposable
}
Вы не сомненно правы, гвозди надо забивать молотком, а не отверткой.
А вопрос вполне корректен. Скорее мой ответ расплывчат — «да, в C# есть деструторы, но они реализованы через финализаторы». А уж то как использовать и использовать ли вообще — это приведет нас к долгому разговору о сборщике мусора и совершенно излишне для данного вопроса.
А вопрос вполне корректен. Скорее мой ответ расплывчат — «да, в C# есть деструторы, но они реализованы через финализаторы». А уж то как использовать и использовать ли вообще — это приведет нас к долгому разговору о сборщике мусора и совершенно излишне для данного вопроса.
Их невозможно реализовать в классическом сборщике мусора (mark & sweep). Если используется подсчет ссылок то еще возможно, но такая модель не умеет удалять циклические ссылки, поэтому велика вероятность что деструктор вызовется не сразу, а когда до него дойдет GC.
Скромно назвать Роба Пайка «одним из разработчиков Go»… :-)
Я длительное время не понимал некоторые виды современного искусства. Ну, знаете, кино в котором 40 минут показывают стоящую посреди комнаты табуретку. Или инсталляцию, где на тумбочке стоит стакан, а в нём скомканная газета. Мне многие рассказывали, что это гениально, а я «просто мыслю шаблонно, а тут надо иначе, по-новому!».
А недавно я смотрел репортаж с одной такой выставки. Показывали там один экспонат (только что был продан за нереальные тыщи баксов) — кусок бревна, с одной стороны покрашен розовой краской. Журналист подходит к автору сиего гениального творения и дальше диалог:
"-Скажите, а что это за дерево? Дуб? Ольха?
-А я не знаю.
-Ок, а что символизирует этот экспонат?
-Я не знаю. Это кусок бревна, покрашенный розовой краской."
И вот тут я понял что значит «мыслить по-новому».
А недавно я смотрел репортаж с одной такой выставки. Показывали там один экспонат (только что был продан за нереальные тыщи баксов) — кусок бревна, с одной стороны покрашен розовой краской. Журналист подходит к автору сиего гениального творения и дальше диалог:
"-Скажите, а что это за дерево? Дуб? Ольха?
-А я не знаю.
-Ок, а что символизирует этот экспонат?
-Я не знаю. Это кусок бревна, покрашенный розовой краской."
И вот тут я понял что значит «мыслить по-новому».
Вы наступили на тему, которую еще Зощенко сто без малого лет назад поднимал. Современное концептуальное искусство очень трудно отличить от шарлатанства. Но можно. Формальный критерий есть, причем он доступен каждому, даже тому, кто в искусстве не разбирается (мне, например).
Возьмите работы этого художника от его первой мазни в пять лет в детском садике на стене и до той работы, смысл которой вы не в силах уловить.
Если вы увидите двести брёвен, покрашенных краской с одной стороны, значит перед вами человек, который умеет только красить с одной стороны брёвна.
Если некоторые из работ вызовут у вас какие-то мысли или чувства, уцепитесь за них и попытайтесь проследить изменения в образах и в стиле. Например, у великого (на мой скромный взгляд) Сальвадора Дали до его «параноидально-критического» периода было огромное количество весьма не-шизофренических картин. Если посмотреть, что он рисовал и в каком порядке, станет видно, что он рос, пока не дорос до «мягкого автопортрета» или слонов на страусиных ножках.
Суть творения не в том, чтобы нанести краску на холст правильно. Можно просто выплеснуть чернила на холст. Суть в том, что посмотрев на полученную кляксу, художник в одном случае из тысячи увидит там свою лучшую работу — и только эту кляксу он предъявит общественности. Улавливаете?
Так что работы настоящего творца всегда показывают его развитие. Работы штамповщика неотличимы одна от другой как шаржи, которые нарисуют на вас и ваших друзей ремесленники с Арбата. А шарлатан плеснет краски на холст и попытается это толкнуть за миллион, сделав «покерфейс» в стиле «сами ищите смысл в моей гениальной работе». Но прошлого, которое в силах понять каждый — у него нет.
По моему наглому мнению, большая часть того, что вы видите на современных выставках — профанация, построенная на всеобщей неразборчивости в искусстве.
Возьмите работы этого художника от его первой мазни в пять лет в детском садике на стене и до той работы, смысл которой вы не в силах уловить.
Если вы увидите двести брёвен, покрашенных краской с одной стороны, значит перед вами человек, который умеет только красить с одной стороны брёвна.
Если некоторые из работ вызовут у вас какие-то мысли или чувства, уцепитесь за них и попытайтесь проследить изменения в образах и в стиле. Например, у великого (на мой скромный взгляд) Сальвадора Дали до его «параноидально-критического» периода было огромное количество весьма не-шизофренических картин. Если посмотреть, что он рисовал и в каком порядке, станет видно, что он рос, пока не дорос до «мягкого автопортрета» или слонов на страусиных ножках.
Суть творения не в том, чтобы нанести краску на холст правильно. Можно просто выплеснуть чернила на холст. Суть в том, что посмотрев на полученную кляксу, художник в одном случае из тысячи увидит там свою лучшую работу — и только эту кляксу он предъявит общественности. Улавливаете?
Так что работы настоящего творца всегда показывают его развитие. Работы штамповщика неотличимы одна от другой как шаржи, которые нарисуют на вас и ваших друзей ремесленники с Арбата. А шарлатан плеснет краски на холст и попытается это толкнуть за миллион, сделав «покерфейс» в стиле «сами ищите смысл в моей гениальной работе». Но прошлого, которое в силах понять каждый — у него нет.
По моему наглому мнению, большая часть того, что вы видите на современных выставках — профанация, построенная на всеобщей неразборчивости в искусстве.
Как обычно, некоторые комментарии интереснее статей.
Можно ли отсюда делать вывод, что если автор языка Go до этого сделал десяток хороших вещей, то и сам язык автоматически — хороший?
Нет, разумеется. Как нельзя сделать вывод, что каждая работа гения — гениальна.
Но в случае с математикой (к которой относится проектирование ЯП), если талантливый умный человек, не впав в маразм, и уже явив миру ранее ряд примеров своего ума и таланта, предоставляет очередной результат своей деятельности — скорее всего это по крайней мере не полная чушь — так ведь? ;)
Скандальный пример. Недавно Дональд Кнут высказывался о том, что многопоточное программирование — тупиковая ветвь развития компьютерных технологий. Если бы это сказал я или ваш сосед по подъезду, вы бы, скорее всего сочли его дремучим. Но когда такое заявление позволяет себе один из живых столпов истории программирования — начинаешь всерьёз задумываться, что он имел в виду (хотя он и постарел весьма, увы...)
Но в случае с математикой (к которой относится проектирование ЯП), если талантливый умный человек, не впав в маразм, и уже явив миру ранее ряд примеров своего ума и таланта, предоставляет очередной результат своей деятельности — скорее всего это по крайней мере не полная чушь — так ведь? ;)
Скандальный пример. Недавно Дональд Кнут высказывался о том, что многопоточное программирование — тупиковая ветвь развития компьютерных технологий. Если бы это сказал я или ваш сосед по подъезду, вы бы, скорее всего сочли его дремучим. Но когда такое заявление позволяет себе один из живых столпов истории программирования — начинаешь всерьёз задумываться, что он имел в виду (хотя он и постарел весьма, увы...)
Нет. Можно сделать вывод, что если автор языка Go участвовал во многих, не побоюсь этого слова, революционных проектах, то его мнение представляет немалый интерес и имеет какой-то вес. О качестве конкретно языка Go это говорит в лучшем случае косвенно.
Полагаю, негодование автора вызвано как раз тем, что ремесленники-шаржисты с Арбата берутся критиковать работы Сальвадора Дали.
С аргументацией, созвучной верхнему комментарию bigfatbrowncat: «Задача художника — изобразить то, что задали изобразить, да побросче и побыстрее. А этот Дали какой-то фигнёй страдал, никаких практических задач его мазня не решает, да там вообще фиг разберёшь, что нарисовано.»
С аргументацией, созвучной верхнему комментарию bigfatbrowncat: «Задача художника — изобразить то, что задали изобразить, да побросче и побыстрее. А этот Дали какой-то фигнёй страдал, никаких практических задач его мазня не решает, да там вообще фиг разберёшь, что нарисовано.»
Скажите, кто в курсе, наверное, это больше вопрос к powerman, а Inferno окончательно похоронили (судя по активности, а точней неактивности в репозитории и около-инфернальным ресурсам)?
Если это так, то это очень печально :(
Хоть Go радует.
Если это так, то это очень печально :(
Хоть Go радует.
Мне о похоронах ничего не известно. :) Inferno продолжает работать и использоваться, И имея возможность выбирать между Go и Inferno/Limbo многие (среди тех немногих, кто вообще использует Inferno, разумеется) выбирают Limbo. Дело в том, что разрабатывая на Limbo наши приложения работают в очень простой среде Inferno, а программы на Go вынуждены иметь дело со всей сложностью и кривизной POSIX. Из-за этого писать на Limbo значительно проще, чем на Go. Да и как язык Limbo заметно проще (впрочем, у этого есть и недостатки — немного большая многословность и сложности с вещами вроде конвертацией между JSON и структурой данных).
Ну, как контраргумент, могу сказать (не холивара ради, а просто интересно ваше мнение), что, например, в Inferno до сих пор отсутствует поддержка x64, что в свою очередь накладывает жестокое ограничение по использованию памяти, не говоря уже о большей производительности x64-операций, а тем более, если использовать Inferno/Limbo по-взрослому, то все равно придется иметь дело с внешней средой и кривизной POSIX и использовать, вероятно, костыльно-велосипедные биндинги для всяких монгодб, редисов и прочих обвязок, не считая бесчисленного множества уже существующих *nix-тулз, во избежания нагромождения собственных велосипедов… Также создается впечатление, что разработка просто застыла, судя по чейндж-логу, вялая динамика настораживает… Мне нравится концепция Inferno и будет печально, если, ну, вы понимаете… Насколько вообще оправдано делать ставку на эту систему в долгосрочной перспективе? Нет ли риска, что в ближайшем будущем ее развитие полностью остановится, особенно учитывая столь небольшое коммьюнити вокруг этой системы и то, что ее авторы, фактически, ушли в гугл и переключились на Go? Наверное, если все ужать, то коротко можно спросить так — у Inferno OS есть будущее?
ограничение по использованию памятиLimbo расходует память крайне экономно. Память, требуемая абсолютному большинству приложений — это десятки килобайт. Оконный менеджер кушает сотни. Килобайт. Вообще, Inferno проектировалась в том числе для работы на устройствах с 1 (одним) мегабайтом памяти. Так что ограничения 32-бит появятся не раньше, чем Вам будет необходимо держать в памяти несколько гигабайт своих собственных данных. Но в этом случае, скорее всего, Вам понадобится не только держать их в памяти, но и обрабатывать параллельно на всех процах/ядрах, так что Вы всё-равно запустите несколько процессов Inferno, и у Вас будет доступ к 2-4 гигам памяти на каждый процесс. Так что задействовать 8-64 гига памяти при необходимости вполне возможно.
большей производительности x64-операцийЭто миф. В реальной жизни до сих пор 64-битные приложения обычно медленнее. Иногда в несколько раз (конкретно сейчас в Gentoo почему-то emerge на 64-битной системе примерно в 3.5 раза медленее чем на 32-битной).
все равно придется иметь дело с внешней средой и кривизной POSIXНе придётся — из инферно всё это недоступно в принципе.
костыльно-велосипедные биндинги для всяких монгодб, редисов и прочих обвязокЕсли они будут нужны — да, свои обвязки надо будет написать. Один раз, точно так же, как они были написаны для всех других языков. Но чаще оказывается, что они не нужны — в инферно используется иной подход к написанию приложений и архитектуры, и необходимость использовать многие привычные инструменты просто отпадает т.к. в инферно не возникают те проблемы, которые решались этими инструментами.
бесчисленного множества уже существующих *nix-тулзА что мешает продолжать ими пользоваться? Если рассматривать инферно просто как runtime для запуска своих приложений (как Java), то ничего не мешает продолжать пользоваться существующими тулзами для, например, анализа логов — никакого смысла переписывать их на Limbo нет, если только Вы не собираетесь использовать инферно как основную ОС на телефоне, например.
Нет ли риска, что в ближайшем будущем ее развитие полностью остановится, особенно учитывая столь небольшое коммьюнити вокруг этой системы и то, что ее авторы, фактически, ушли в гугл и переключились на Go?Это не совсем так. Во-первых, скорость разработки инферно практически не меняется последние лет 15. Во-вторых, изначальные авторы инферно примерно столько же лет ей не занимаются, а занимается ей Чарльз Форсайт, который никуда не ушёл.
у Inferno OS есть будущее?Если мы говорим про светлое будущее, то я не уверен есть ли оно у Go (в рейтинге популярности языков он всё ещё очень далеко, и не факт что значительно поднимется), и уж тем более его точно нет у инферно. Если мы говорим просто про возможность использовать его в продакшне — она есть уже лет 10, и ждать какого-то будущего необходимости нет. Я уже молчу про то, что простое изучение инферно и его исходников очень многое дают для саморазвития как программиста, даже если не использовать его в реальных проектах — и эта возможность тоже есть уже сейчас.
Спасибо за развернутый ответ. А что, если я, к примеру, чисто гипотетически, решу строить свой сервис на базе Inferno, обслуживающий мобильных клиентов, получается, что мне для каждой мобильной платформы и того языка, на котором написан клиент, будет необходимо искать, а возможно даже и портировать, реализацию протокола Styx? Я знаю, что есть некоторые готовые реализации, но ведь динамика развития и появления новых мобильных платформ (всякие тизены, фаерфоксосы, вендафоны, етц..) гораздо выше той же динамике появления/развития и поддержки тех же портов Styx… Как быть тут? Использовать сокеты, ssl, protobuf-ы и прочее, что имеет более широкое развитие и поддержку и есть ли эта возможность из Limbo вообще?
Во-первых, на Limbo можно написать практически любое типичное приложение. Я лично пишу кучу сетевых сервисов, которые работают через обычный TCP, а данные передают в JSON. Никакого Styx. К сожалению (это вызвано необходимостью взаимодействия с кучей уже существующих сервисов, которые писались на Perl во времена, когда я с Inferno ещё не работал).
Во-вторых, насколько я знаю, по крайней мере на Android-телефонах можно установить Inferno как обычное приложение. Не знаю, как из него взаимодействовать с фичами андроида (если они доступны только из API Java, то возможно придётся написать простенький сервис на Java дающий доступ к этому API через TCP на localhost — чтобы к нему смог подключиться код работающий внутри Inferno), но Styx будет работать великолепно. :)
Во-вторых, насколько я знаю, по крайней мере на Android-телефонах можно установить Inferno как обычное приложение. Не знаю, как из него взаимодействовать с фичами андроида (если они доступны только из API Java, то возможно придётся написать простенький сервис на Java дающий доступ к этому API через TCP на localhost — чтобы к нему смог подключиться код работающий внутри Inferno), но Styx будет работать великолепно. :)
Спасибо за разъяснения!
К слову говоря, я уже как-то пробовал развернуть Inferno на своих девайсах под андроидом, сначала я разворачивал на них убунту с помощью Linux Deploy, потом по вашей инструкции для убунты с небольшими правками (ибо арм) у меня получилось ее собрать… :) (в сундуке заяц, в зайце утка, в утке...)))
И даже запускается и даже работает)) Но вот запустить у меня получилось только в консольном режиме, при попытке запуска в графическом режиме она ругалась, дословно не помню, но что-то типа, что ей недостаточно 16 битной глубины цвета и завершалась… :( Может вы в курсе, что тут можно сделать, может где-то при сборке в конфигурации можно прописать значение глубины цвета или при запуске где-то что-то можно указать или еще как?
И даже запускается и даже работает)) Но вот запустить у меня получилось только в консольном режиме, при попытке запуска в графическом режиме она ругалась, дословно не помню, но что-то типа, что ей недостаточно 16 битной глубины цвета и завершалась… :( Может вы в курсе, что тут можно сделать, может где-то при сборке в конфигурации можно прописать значение глубины цвета или при запуске где-то что-то можно указать или еще как?
Когда я вижу фразу «код бы получался более живой и яркий» — я понимаю что уровень bullshit этого текста просто зашкаливает. Код это код, он выполняет задачу.
«Programs must be written for people to read, and only incidentally for machines to execute.» (ц)
Пост о профессионализме. Можно с легкостью заменить название профессии, переписать пару абзацев и получить текст о некомпетентности человека в другой технической области.
Да, везде есть люди называющие себя «инженерами», которые не являются таковыми по сути.
Да, везде есть люди называющие себя «инженерами», которые не являются таковыми по сути.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Воображение, как у Эсмеральды