Pull to refresh

Comments 33

Крутая статья. Спасибо :)

А что делать тем же самым начинающим разработчикам, которые только начинают изучать программирование под ios? Имеет ли им смысл начинать сразу со свифта без «потери времени» на obj-c или нет?
Obj-C даст понятие откуда ноги растут у всех NS-классов и системных API в iOS.
UFO just landed and posted this here
Язык не столь важен, его освоить можно быстро. Важно знать системные фреймворки и инструменты. На каком языке найдёте подходящий обучающий материал, на том и осваивайте.
UFO just landed and posted this here
Ой, спасибо. Вступление к материалу готовил ещё до появления этой новости, а потом на официальный блог поглядывал, но там об изменении планов не сообщали. Отредактировал теперь текст.
Ну и, кстати, запланирована не на 4.0, а просто на «после 3.0», так что может попасть уже в 3.x:

> Quite sad we could not get into ABI stability for Swift 3… but are we talking Swift 3.1 or 4.0?

We’ll start discussing post-3.0 releases in August. Until Swift 3 is really wound down, it is almost impossible to make forward looking plans.
При прочтении статьи вспоминается собственный опыт разработки программно — аппаратных систем с 1973 года, в рамках лаборатории АСУ и АСУТП и не только…

вначале был аппаратно — ориентированный ассемблер (о коболе и фортране не упоминаю) C, потом Бейсик ориентированный на решение простейшего класса задач, Quasic, разработанный в Пущино — аппаратно — ориентированный бейсик, прошли стройными рядами Паскаль, DOS, первых XT and AT, с частотами процессоров 4.7 мгц, PHP, Java…

и, наконец, по проишествии 43 лет все вернулось к C#, а до этого к Паскалю — Delphi.

Ныне похоже начинается новый круг, по спирали вверх, как положено в диалектике, ASP.NET 5, потихоньку умершая с переходом к Core 1.0…

А ведь сколько шуму было, когда на сайте майкрософт я написал в середине 2015 статью «Почему я выбираю Windows 8.1 и WebForms?» где я доказывал, что пока ASP.NET 5 (тогда такое было название нового чуда) станет на ноги и обзаведется UI — элементами пройдет ну лет 5 минимум, вследствие чего остается только ориентироваться либо на MVC, либо на Web Forms…
Как не старался но не уловил связи между «43 года», «все вренулось», «C#», как вы умудрились их связать в одном предложении?
Так это нисколько не удивляет! Многие люди до сих пор не понимают, какая существует связь между парадными и подъездами, бордюрами и поребриками. Про использование мягких знаков в рамках средней школы я лучше вообще промолчу. Это, ведь, не главное! Главное — инновации и свежий взгляд! А то, что этот свежий взгляд уже давно устарел — ерунда. Важнее, что пипл схавает.
Если вы мне докажите, что свежий взгляд давно устарел буду очень рад. О себе — последняя должность на оборонном заводе — зам. генерального директора… ныне в США, где делал проекты в т.ч. для НАСА, многократно приглашался в Россию для руководства собственным проектом, по сложности много превосходящим гугл, фейсбук и пр.
Поясняю, я работал на оборонном заводе, в отраслевой лаборатории АСУ и АСУТП, в далеком 1976 году спроектировал и реализовал в «железе» — на 580 серии, на ассемблере, интерполятор — систему управления станками с ЧПУ токарной и фрезерной группы… забавно, но с тех пор по проишествии 40 лет в России так никто и не реализовал ничего подобного — все что делается ныне, делается на контроллерах практически той же серии, но Сименс. Что формально изменилось за 40 лет в области ПО по обеспечению автоматизации процессов, а не генерации мегатонн макулатуры, какой завален интернет? да ничего!

Тогда же появились одноплатные эвм мс -1201, с вшитым бейсиком, с функциями в принципе во многом схожими с нынешним бейсиком, что нынешнюю публику безусловно устроило, но не тех кто занимался автоматизацией процессов, нужен был бейсик способный работать с железом, таковой появился — квейсик. Что формально изменилось? бейсик 1974 — 1976 в одноплатной эвм и нынешний отличаются только функциями…

С, Unix, паскаль — это все то время — им соотвествует C#, Delphi нынешнего времени…
Сдается мне C и C# совершенно разные вещи и совершенно не соответствуют друг другу.

И опять же мне не понятно «так и не реализовал ничего дободного».
Посмотрите мое био, чтобы легче было понять друг друга…

Я не чистый программист, а разработчик программно — аппаратных комплексов, с соответствующими запросами к функциональности ПО… в настоящий момент реализую проект, вероятно, наиболее сложный в моей карьере… что из этого выйдет посмотрим… и откровенно говоря меня интересует только эта тематика — на интернете к сожалению пока не нашел никого с кем можно было поговорить на эту тему, за исключением коллег, занимающихся американской системой Сократ
Относительно «так никто и не реализовал ничего подобного» в России… имеется ввиду создание полностью ПО и аппаратных средств на 580 серии — специализированные контроллеры Сименс, реализующие те же функции, как в части программных, так и аппаратных средств, созданы не в России.

Относительно простых языковых средств — С и C#, бейсика тех времен и нынешних принципиальных отличий не имеется — и тот и другой язык НЕСОВЕРШЕННЫ для реализации даже простых стендов… программно — аппаратный комплекс для НАСА мне пришлось реализовывать на Матлабе — C#, Delphi для этого не годятся…
В 80-х годах у отца на заводе трудились ЧПУ полностью советской разработки на базе 16 битного МП 18хх серии, точнее не помню к сожалению. Т.к. создавали подобное, очень даже создавали.

Насчет программно аппаратного комплекса, уж если надо управлять железом в реальном времени, то C# там точно делать нечего, это людой разработчик скажет, а вот тому самому C очень даже место.
я прекрасно знаю, причем в деталях о чем вы говорите — об мс — 1201, позже их назвали «электроникой». Делали их на Кванте в Зеленограде, мы на них много чего делали. Где — то в 1980 на них появились первые системы управления станков токарной и фрезерной группы… с тех прошло достаточно много времени те одноплатки уже давно нигде не применяются

Я говорю о системе на базе к580 — вот они да — применяются везде, только не российская или ссср — кая разработка, а сименовская
Относительно C# и C для управления программно — аппаратным комплексом… вы видимо не очень хорошо представляете реальные задачи и необходимые в связи с этим программные средства. К примеру средства Матлаба содержат прикладные пакеты, которые в C или C# пока не предполагаются в будущем…
На ХабраХабре я видимо заканчиваю участие по нескольким причинам:

1. здесь очень странная система оценки, когда все что касается собственного опыта оценивается отрицательными оценками, притом что я действительный член одной из американских академий…

2. статья посланная мной в адрес редакции о системе, о которой в России вообще никто не знает, была редакцией отвергнута, притом что моя пояснительная записка об этой системе отправленная в адрес Админ. Президента была сразу переадресована в Мин. Обороны…
Ув это так, с этим можно только смириться.
Речь в статье идет об американской системе «Сократ», о которой есть очень краткое упоминание в английской версии Википедии — эта система проектируется с 1983 года под эгидой военной разведки США. Ныне третья версия системы позиционируется как Супер — Академия наук, обеспечивающая «генерацию» технологий.

Система прошла обкатку в крупнейших компаний США и положена в основу закона H.R. 516 Return Jobs in America Act от ноября 2011. Назначение системы — обеспечение технологического отрыва от России и Китая на поколения. В настоящее время система разворачивается по всей территории США.

С руководством этой системы я знаком лично… и лишь по одной причине — занимаюсь этими же вопросами — ре — индустриализации и т.п. в середине 2012 (до дела Сноудена) я выступил инициатором разворачивания системы Сократ и в России тоже. Полгода велись видеоконференции на уровне руководства системы Сократ, Деловой России с моим участием…

ну и т.д.

Забавным является то что охламонов из хабрахарбора это не заинтересовало…

ну да ладно… проблема в том, что по данной тематике не могу найти на интернете никого с кем бы можно было иногда поговорить по этой тематике…
с трудом но вспоминаю, но на мс — 1201, первых одноплатных эвм (до электроники нц), использовались процессоры не 1801 — 1811, а другие, название не вспомню, к нам на завод вначале пришли все комплектующие, без фотошаблонов и печатных плат и я паял все вручную, возможно, до десятка тысяч проводов, наводки конечно были страшные…
«Новые языковые конструкции, такие, как дженерики, отсутствующие в Objective-C»
Видимо Максим не вкурсе, но вообще то дженерики есть в Obj-C
В Obj-c нет compile-time дженериков, а есть только Lightweight Generic, которые мало что имеют общего со Swift'овыми. По сути это просто sintax sugar.
Хм. Игорь уже в Баду и на Свифте :) Молотком.

По теме. Свифт берет от всего понемногу, но слишком много всего берет, и часто из-за backward и legacy. То же управление памятью — явно костыль совместимости. Мне он напомнил C#, который обрастал костылями и фичами, но в его случае сложнее отличить одно от другого :)

Про себя могу сказать, что со Свифта ушел на Xamarin, как только последний стал бесплатным. Сейчас все языки уже обросли костылями (а Свифт в этом оказался очень быстр), даже любимый JavaScript, и если бы Telerik не был бы таким жадным, возможно и тот же Xamarin бы не был так популярен. В любом случае на мой взгляд C# и JavaScript наименьшее зло в плане баланса порога вхождения (не так уж он и низок у Свифта) и широты инструментария (речь о мобильных приложениях средней сложности).
Может тогда поясните, почему во многих других языках его все же нет, и они популярны, и на них пишут?

Я сам на плюсах писал очень долго, и говорю не о том, что «GC хорошо», а «управление памятью плохо». Надеюсь что я не настолько примитивно понимаем. Memory Management скорее пример в случае Swift (хотя очень наглядный, так как без этой сознательной фичи много чего не сделать при создании UI), я писал о другом вобщем-то — о пороге вхождения больше.

Лично меня послушать — все языки с костылями (я когда-то свой делал, без них очень сложно что-то сделать), и даже ООП в моем понимании -«костыль», призванный в свое время упростить, убыстрить и переиспользовать, а по факту приведший к усложнению архитектур вместо микромодульности.
Я не специалист по тому, как развивались подходы к управлению памятью, но могу предположить, что так исторически сложилось. Английская Википедия упоминает, что первый сборщик мусора был применен в Lisp еще в 1959, а автоматический подсчет ссылок в схожих масштабах был использован Apple только в 2011. Т.е. к моменту появления той же Java в 1995 году, mark-sweep GC, видимо, были куда более проработанным вариантом. Хотя в том же году вышел Delphi 1, где подсчет ссылок использовался для управлением строками и динамическими массивами.

Можно еще рассмотреть ARC, как он реализован в Objective-C. Круговые зависимости разрываются с помощью слабых ссылок, т.е. с каждым объектом может быть связана своя таблица слабых ссылок, которые надо обнулить, когда объект помрет. Доступ к таблице должен быть синхронизирован, что делает слабые ссылки узким местом в мнопоточном коде. Это плохо для серверных приложений.

В Свифте эту проблему решили, изменив то, как сделаны слабые ссылки. Во-первых, счетчики слабых и сильных ссылок хранятся в старших разрядах указателя на объект, что позволяет использовать атомарные операции для их изменния. Во-вторых, больше нет никаких таблиц, потому что обнуление слабых ссылок — ленивое, в момент обращения к ним. Отсюда интересное следствие: объект на который есть слабые ссылки сначала превращается в «зомби», а окончательно осовбождает память только когда обнулится последняя слабая ссылка.
Не слышал о серверных приложениях на Свифте или Objective-C. На C#/python/node.js слышал/видел/писал (и на С++ правда тоже). Не суть. Со времен появления коммерческого программирования сложилось так, что языки не для того делают в своём большинстве чтобы разные технологии в их основе применять.

Даже банально пример из сайтостроения — при проектировании информационной архитектуры подсчитывают, сколько шагов посетителю нужно сделать до достижения цели (а потом и качество того что получит, оценивают). Если сравнивать код на шарпе и на свифте… без Xamarin.Forms есть взять — то это практически те же фаберже, только без магии ссылок, по сути заботы о ЖЦ объектов. Забота о ЖЦ не есть плохо с точки зрения напряжения мозгов, это есть плохо с точки зрения поддерживаемости и расширяемости, переносимости на другие языки и читаемости кода в целом (у Макконнела есть понятие cohesion — связности), и, возвращаясь к примеру с сайтами — увеличение числа шагов по достижению цели, и конечная картина не столь ясная.

Конечно, начудить плохого кода можно где угодно. И конечно, тому кто владеет инструментом, всё ни по чем. Я же в своё время был разочарован Свифтом, хотя и возлагал на него очень большие надежды, и когда-то был рад анонсам портирования на другие платформы. Потом взвесил шашечки и ехать, и пришел к выводу для себя лично.
по сути заботы о ЖЦ объектов

я бы не назвал это заботой о GC, а назвал бы сознательным обдумыванием object graph программы и отношений владения, чтобы правильно расставить слабые ссылки. Это полезно даже при наличии GC.

ЖЦ — это Жизненный Цикл
с плюсами бы без obj-c прослойки начал работать — было бы замечательно. так в целом понравилось на нем программить.
Sign up to leave a comment.