джава и сишарп — это динозавры, который застыли во времени. громоздкие и с избыточным синтаксисом. сейчас появились более современные и удобные языки, с которыми работать гораздо комфортнее. и потому программисты будут переходить на них. если сишарп и джава не начнут шевелиться и эволюционировать, то ничего хорошего им не светит.
Z>>да, то что я и хотел сказать. после того, как поработаешь с тем же свифтом, переходить обратно на сишарп — это пипец мучение. BS>а что там такого в Swift отчего потом мучения в C#?
Здравствуйте, Mamut, Вы писали:
M>>>.net туда прекрасно вмещается. У нас половина микросервисов на .net core
>>> Initial release June 27, 2016; 3 years ago[1] C>>этим всё сказано, лавинообразный рост отрасли был в 2013-2015 гг.
M>Что сказано?
C>>возьмите образовательные ресурсы и найдите на них C#, он только в геймдеве представлен.
M>И? Из того, что на образовательных ресурсах C# представлен в геймдеве, я должен делать какие-то далеко идущие выводы? Я моуг взять, например, Google Cloud. Ой, ты посмотри. C#/.Net среди платформ, которые напрямую поддерживаются Гуглом. Этот показатель гораздо лучше, чем «ой, на курсере C# только для игр».
старперам нет дороги, тупиковое поколение.
net core поздно появился, уже другие инструменты успешно используются, нахрен никому не нужен net core и net программисты, так как прироста новой крови в net сообщество нет.
Еще что нибудь очевидное пояснить?
Моё имхо — линукс окончательно вытесняет венду на серверах. .NET конечно научился чего-то там делать на линуксе, но Java всё равно более надёжный выбор. Плюс у жавы есть огромный рынок андроид-приложений, который в какой-то степени помогает и серверной жаве, у .NET такого рынка нет. Был огромный рынок десктопов, но тут ровно та же ситуация, десктопы стагнируют, а мобильные устройства цветут и пахнут.
ИМХО микрософту нужны убойные технологии. Если ничего крутого на .NET не выстрелит, они уйдут в небытие рано или поздно. Java это хорошая технология, за ней реет дух свободы. Язык, конечно, уступает C# но на практике это не критично, а многие шарперы вообще не в восторге от такой кучи нововведений, т.к. не осиливают их.
Что .NET может сделать, это единую платформу для всего. Windows, Linux, macOS, iOS, Android, Web. Вот это всё. Сейчас тут сидит JavaScript и скоро придут другие языки на Wasm. Но дело не в основах, а в прорывных фреймворках. Например у JS такой фреймворк это React и его клоны вроде Vue. У Микрософта есть Mono, надо брать его наработки, надо делать хорошую компиляцию в JavaScript, надо писать GUI для всех платформ и очень быстро. Уверен, лет через 5-10 будет куча всего нового и если микрософт в этом не поучаствует, он уйдёт. А если появится технология, с популярностью хотя бы уровня React Native, чтобы люди шли и писали одно приложение на все платформы и оно реально работало на уровне натива, с вылизанными библиотеками и вибрирующим коммьюнити, .NET может всех опрокинуть.
Здравствуйте, Mamut, Вы писали:
Z>>джава и сишарп — это динозавры, который застыли во времени. громоздкие и с избыточным синтаксисом. сейчас появились более современные и удобные языки
M>Это какие?
котлин, свифт, питон ...
Z>>, с которыми работать гораздо комфортнее. и потому программисты будут переходить на них. если сишарп и джава не начнут шевелиться и эволюционировать, то ничего хорошего им не светит.
M>Это C# не эволюционирует? Бггг. C# в 2005-м, скажем, и в 2019-м это вполне два разных языка. Java эволюционирует медленнее потому что у нее гораздо больше груз обратной совместимости.
это не та эволюция, которая от них ожидается. накидывание новых интерфейсов или расширений — это не эволюция, а расширение функционала. эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны, перекладывание части работы на компилятор и так далее. в джаве для андроида, по крайней мере до недавнего времени (а может и сейчас), так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера. казалось бы, маст хэв, но делается через одно место. и все потому что — динозавр.
если бы свифт был под виндой, я бы только на нем и сидел и забыл бы о сишарпе как страшный сон.
Здравствуйте, Mamut, Вы писали:
M>Мал золотник, но дорог. Андроид одновременно пробил и отметку в 90% и дно. 90% от этих 90% — это бюджетные телефоны с нулевой отдачей.
1) Флагманы андроидные не сильно дешевле, а иногда и дороже.
2) Продаётся их всяко не меньше чем флагманов эпла.
3) у эпла есть и бюджетные модели
А самое главное — какая корреляция между бюджетностью телефона и его отдачей ?
Правильно, никакой.
Видел исследования, в которых основную прибыль для игровой индустрии генерят малообеспеченные люди.
M>Больше половины доходов в мобильных приложениея генерирутеся приложениями на iOS
Славно пригорело.
Речь о рыночной доле телефонов. И да — доля эпла только снижается. Причём тут доходы мобильных приложений ?
Когда эплобою возразить хочется, но нечем, он начинает хвастаться как качественно его умеют доить.
Здравствуйте, okon, Вы писали: O>Тут помоему единственное нормальное решение — if ( code >= 200 && code <= 299 )
Ну, так там же главное — доказать превосходство Swift. Тут никакое враньё не будет чрезмерным.
А нормальных решений там и так накидали. Причём и синтаксически, оказывается, можно свифт превзойти.
Ну, и как бы сам пример показательный — в нормальном коллективе такой код ревью не пройдёт; потому что магические константы и диапазоны. Единственный верный вариант привёл Mamut — тот, где IsSuccesfullResponse. Потому что он единственный остаётся понятен и через 10 лет после увольнения автора, и даже новичку, который протокол HTTP впервые видит (и о соглашении про 2xx в жизни не слыхал).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
BS>что ты мелешь? на историю моих сообщений посмотри, меня тут почти не бывает, а больше года я вообще на форуме не был
ну а ты мою историю посмотри, я тут тоже нечасто. и почему ты решил, что я с тобой что то обсуждал? у тебя с головой порядок?
BS>да понятно уже все, что конкретики не будет, ок
разумеется, зачем мне поощрять твою лень? либо принимай на веру, либо приводи свои мысли, либо гуляй мимо. я тебя не звал, а сказал свою точку зрения. доказывать тебе ее, особенно сейчас, после того, как ты начал агрессировать — не собираюсь тем более
Здравствуйте, IID, Вы писали:
IID>fixed
Да сколько ни чини, все вменяемые люди под термином "выстрелил" по отношению к продукту понимают финансовую отдачу.
Если верить вашей статистике о том, что iOS устройств в 10 раз меньше, чем Android, то с учётом неумолимого графика, приведённого Mamut, выходит, что каждый пользователь iOS приносит разработчикам приложений в 12 раз больше денег, чем пользователь Андроида.
Это как бы полностью опровергает смелые предположения о том, что "на самом деле нищие пользователи хуавья платят больше денег за приложения, а пользователи эпла отдали последние штаны и кроме вацапа ничего не качают".
Поэтому лучше подобные идеи в ближайшие годы (до обновления статистики) публично не высказывать — засмеют.
Если хочется выступить в защиту андроида, то нужно делать это аккуратно, например так: "несмотря на более низкую ARPU андроид-устройств по сравнению с устройствами на iOS, в последние годы рост продаж этих устройств в значительной мере скомпенсировал этот перекос. Поэтому сегмент android-приложений постепенно догоняет по объёму сегмент iOS-приложений, что мотивирует разработчиков шире пользоваться кросс-платформенными фреймворками для удешевления входа в оба сегмента".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mamut, Вы писали:
M>Вообще, .net начинался 20 (!) лет тому назад, как строго windows-only технология в условиях, когда Винде не было и не предвиделось альтернатив.
ты преувеличил немного. 20 лет назад — это 99-ый год (ну почти 0-ой). дотнет появилась в 2002-ом, как счас помню.
Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass.
.
Z>то есть, конструкция Z>
Z>guard let foo = ...
Z>
Z>в данном примере одновременно объединяет в себе и приведение типов и проверку на нуль. в данном пример + еще и проверку на совпадение в заданном диапазоне. и если любое из двух условий не было выполнено, то выполняется блок else, где из главного потока вызвается Z>
Z>self.authenticationDidFail = true
Z>
Z>опять так, сравниваем синтаксис создания списка по заданному диапазону в свифте Z>
Z>(200...299)
Z>
Z>против сишарпа
Z>
Z>Enumerable.Range(200, 299)
Z>
Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так:
public static bool Contains(this (int start, int endInclusive) range, int value) => value >= range.start && value <= range.endInclusive;
После этого мы пишем (200, 299).Contains(httpResponse.Code) и волосы становятся мягкими и шелковистыми.
В "старых" версиях С# (начиная с 3.0) мы использовали "прямой" синтаксис httpResponse.Code.IsBetween(200, 299). Z>я уже и не помню, как в сишарпе одной строкой запустить код в главном потоке, потому опустил эту часть.
Да уже видно, что вы просто не владеете C#. Конечно, он вам кажется неудобным. Z>и это только одна конкретная мелочь, коих в свифте, конечно же, можно привести полно. когда проект большой, то таких мелочей вагон и ты начинаешь чувствовать их мощь и удобство. потому каждый раз говорить одно и то же реально задолбало.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>В принципе core может придать второе дыхание, но в целом из-за потери мобильного рынка ms, в которой доля .net могла вырасти в разы, случилась если не стагнация, то S>застой.
Java тоже потеряла мобильный рынок. iOS — это Swift, Android — Kotlin (Java там примерно как Assembler при разработке на C++, например, т.е. рядовой разработчик с ней не столкнется). На Android — Kotlin рекомендованный Google язык разработки, Java поддерживается, но ее используют опять же только для поддержки уже написанных приложений (при этом часто могут перейти на Kotlin почти без ограничений и дополнительных издержек). Ну и до кучи, под Android пишут чаще молодые и перспективные (это не энтерпрайз с их старперами с 20+ лет опыта) и тут подход "Я 15 лет пишу на Java — мне так проще и понятнее" не работает. Там сразу начинают писать на Kotlin и изучать еще один язык (древний и костыльный) ваще не с руки. А если посмотреть на многопоточку на котлиновских корутинах, то в сторону Java останется только плеваться, настолько в ней это не удобно.
и тут же Z>это не та эволюция, которая от них ожидается. накидывание новых интерфейсов или расширений — это не эволюция, а расширение функционала. эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны
Ты точно уверен, что правильно указал swift, например? Z> в джаве для андроида, по крайней мере до недавнего времени (а может и сейчас), так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера.
Это не проблема Java, а проблема Андроида. Благо, http-клиентов на любой вкус в Java как собак нерезаных.
Ну и про красивые API. Я тут недавно пытался файл в свифте прочитать. Прекрасный язык без расширения функционала, а с упрощением синтаксиса и убиранием синтаксических нагромождений, да:
Здравствуйте, Ватакуси, Вы писали:
В>Что случилось с такой перспективной технологией как .net?
не вписалась в рынок. А именно десктоп отдан на откуп web-технологиям, сервер-сайд просран из-за облаков и контейнеризации (core вышел слишком поздно). Остаётся только кровавый энтерпрайз, но зачем писать на дотнет когда есть гораздо более диверсифицированная жава?
В>Что случилось с такой перспективной технологией как .net?
Живее всех живых в виде .net core, который я все чаще вижу, как альтернативу Java в бэкенд-приложениях.
Вообще, .net начинался 20 (!) лет тому назад, как строго windows-only технология в условиях, когда Винде не было и не предвиделось альтернатив. Мобильная и облачная революции произошли всего 10 лет тому назад и далеко не сразу. Падение популярности windows-only .net'а, как ни странно (сарказм), совпало с относительным падением популярности винды, как платформы.
BS>>что ты мелешь? на историю моих сообщений посмотри, меня тут почти не бывает, а больше года я вообще на форуме не был Z>ну а ты мою историю посмотри, я тут тоже нечасто. и почему ты решил, что я с тобой что то обсуждал? у тебя с головой порядок?
ты про мои сообщения стал что то писать. с головой не порядок у тебя
BS>>да понятно уже все, что конкретики не будет, ок Z>разумеется, зачем мне поощрять твою лень? либо принимай на веру, либо приводи свои мысли, либо гуляй мимо. я тебя не звал, а сказал свою точку зрения. доказывать тебе ее, особенно сейчас, после того, как ты начал агрессировать — не собираюсь тем более
действительно, "иди изучи, почитай." "таким как я отвечал уже", "у тебя с головой порядок?" и почему же я стал агрессировать, просто любопытно
Здравствуйте, Flem1234, Вы писали:
F>Можешь хотя бы в нескольких пунктах сформулировать, чем свифт лучше? Ну, например, шарп лучше некоторого условного языка X F>А что может свифт?
пример выше показал то, что умеет делать свифт. и делает он следующие вещи
1. приводит объект из одного типа в другой с проверкой
2. поиск совпадения из заданного диапазона
3. вызов кода в главном потоке
если абстрагироваться от конкретных типов и классов, то переписанный пример на свифте будет следующим
var foo = someObject as ConcreteClass;
var array = Enumerable.Range(200, 299).ToArray();
if (foo == null || !array.Contains(foo.someValue)) {
// запустить в главном потоке код
// self.authenticationDidFail = true
}
то есть, конструкция
guard let foo = ...
в данном примере одновременно объединяет в себе и приведение типов и проверку на нуль. в данном пример + еще и проверку на совпадение в заданном диапазоне. и если любое из двух условий не было выполнено, то выполняется блок else, где из главного потока вызвается
self.authenticationDidFail = true
опять так, сравниваем синтаксис создания списка по заданному диапазону в свифте
(200...299)
против сишарпа
Enumerable.Range(200, 299)
я уже и не помню, как в сишарпе одной строкой запустить код в главном потоке, потому опустил эту часть.
и это только одна конкретная мелочь, коих в свифте, конечно же, можно привести полно. когда проект большой, то таких мелочей вагон и ты начинаешь чувствовать их мощь и удобство. потому каждый раз говорить одно и то же реально задолбало.
Здравствуйте, zverjuga, Вы писали:
Z>когда в оригинальной версии было Z>
Z>guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { // перенес в одну строчку, чтобы было наглядно, что это часть конструкции guard let, аналог AND (&&) в сишарпе
Z> self.authenticationDidFail = true; // этот код работает, когда response НЕ является HTTPURLResponse ИЛИ statusCode не входит в заданный диапазон
Z>}
Z>
Нет, по итогу получается так:
if (response is HTTPURLResponse httpResponse && (200..300).Contains(httpResponse.statusCode) {
return;
else self.authenticationDidFail = true;
Видите — 1:1.
Z>я уже говорил, что я не утверждаю, что в сишарпе нельзя сделать того, что можно сделать в свифте. не нужно мне отдельные куски показывать, нужно показать пример целиком, чтобы была видна разница.
Я и показал. Вы просто передёргиывете. Z>и уже говорил, что прекрасно знаю, как продолжаются и заканчиваются подобные срачи. нет смысла дискутировать, пока оппонент не будет знать предмета разговора. то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Ну вы же не хотите потратить пару вечеров изучить C#. Поэтому критикуете придуманные недостатки.
Я в свифте конечно мало что понимаю, но ваш пример явно выглядит на С# лучше, чем на свифте. Есть риск, что если вы продолжите приводить более интересные примеры, то свифт вообще сольёт даже шарпу трёхлетней давности, не то что 8.0.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Z>причем тут hhtpClient? где ты его в примере вообще увидел?
Да ты что, response, приводимый к типу HTTPURLResponse и проверяемый на успешный status code вообще никакого отношения ни к HTTP ни к клиентам не имеет, ты что.
Z> у тебя есть response непонятного типа, который должен быть приведен к HTTPURLResponse + проведена проверка. откуда ты знаешь, как ты вообще этот response получил? это может быть параметр в функции типа AnyObject.
ага. какой-то сферовакуумный код, в котором неизвестно откуда взявшийся response внезапно надо срочно привести к HTTPURLResponse. Нет конечно. Все это — результат убогого до невозможности API Свифта (что ты там ныл про отсутсвие «нормальных асинхронных HTTP API в Андроиде»?)
// начало вызова комменти ровать не будем,
// отсылка JSON'а немного писец во всех языках
let request = ...;
let task = URLSession.shared.dataTask(with: request, completionHandler: { data, response, error -> Void in
// в этом говне переменные могут быть nil,
// а проверить на nil через if x == nil в общем случае нельзя.
// только присваиванием
// потому что == требует наличия Equatable у любого объекта
// компилятор решить эту проблему не может, видать.
// Но говно с точки зрения зверюги — это почему-то C# и Java, а не Swiftif let error = error {
return
}
// жрем еще говна прекрасным дизайном API
// потому что согласно зверюге, в красивом API ответ от
// хттп-клиента может быть чем угодно, например, AnyObject
// а работать с этим прекрасным асинхронным API надо вприсядку,
// выполняя все действия вручную
guard let httpResponse = response as? HTTPURLResponse,
(200...299).contains(httpResponse.statusCode) else {
return
}
// почему так? Потому что убогое убожество Swift
// неспособно привести одно к другому, а из него достать третье
// у response тип URLResponse? поэтому надо привести к HTTPURLResponse? через as?
// а через что же еще. Больше! Больше доп. синтаксиса! Это не как в C#/Java, это другое
// тут все кривые расширения и добавления синтаксиса, согласно зверюге, это благо
// и программисты все поймут
//
// Но достать из результата приведения value не получится, потому что ? — это скрытый Optional
// и надо его сначала "unwrap" через ! (аналог .get() в Java)
// и результат тоже Optional. Его тоже надо распаковать!
token = (response as? HTTPURLResponse)!.value(forHTTPHeaderField: "x-set-authentication")!
})
теперь сравним это с абсолютно аналогичным кодом на C#
var response = await client.PostAsync("http://www.example.com/recepticle.aspx", content);
if (response.IsSuccessStatusCode) {
// единственный неочевидный момент
// для кастомных заголовков надо вытягивать их вручную
// вместо First можно или FirstOrDefault() для обработки случая,
// если заголовка нет
httpResponseMessage.Headers.GetValues("x-set-authentication").First();
}
Здравствуйте, Mamut, Вы писали:
В>>Что случилось с такой перспективной технологией как .net?
M>Живее всех живых в виде .net core, который я все чаще вижу, как альтернативу Java в бэкенд-приложениях.
M>Вообще, .net начинался 20 (!) лет тому назад, как строго windows-only технология в условиях, когда Винде не было и не предвиделось альтернатив. Мобильная и облачная революции произошли всего 10 лет тому назад и далеко не сразу. Падение популярности windows-only .net'а, как ни странно (сарказм), совпало с относительным падением популярности винды, как платформы.
правильно, с 2007 года linux начал захватывать рынок серверов
вот ваши 10-12 лет тормозов с NET и windows only технологией.
сервера на windows уже никому не уперлись, да и понятие операционной системы для сервера стерлось.
виртуалки на linux на ура захватывают сетевое пространство, NET нуда не вмещается, mono несколько лет назад был поделкой на коленке, уже выросло новое поколение программистов, кому этот NET не уперся.
Z>джава и сишарп — это динозавры, который застыли во времени. громоздкие и с избыточным синтаксисом. сейчас появились более современные и удобные языки
Это какие?
Z>, с которыми работать гораздо комфортнее. и потому программисты будут переходить на них. если сишарп и джава не начнут шевелиться и эволюционировать, то ничего хорошего им не светит.
Это C# не эволюционирует? Бггг. C# в 2005-м, скажем, и в 2019-м это вполне два разных языка. Java эволюционирует медленнее потому что у нее гораздо больше груз обратной совместимости.
Здравствуйте, Mamut, Вы писали:
M>- «так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера. казалось бы, маст хэв, но делается через одно место.».
M>Ага. Вон в Свифте API просто загляденье, ага-ага. Всего-лишь в четыре раза длиннее, чем на C#, все делается в ручную, да еще на коллбэках построено, потому что в async/await Swift не умеет. Причем сам Lattnet говорит, что подобные API — говно и хочет, ой, расширить синтаксис и функционал чтобы получить async/await, акторов и т.п. Но это другое, ага, не то, что в C#
ну раз ты настаиваешь, чтобы эту глупость прокомментировал, то изволь.
асинхронные http(s) вызовы в свифте еще сто лет назад были реализованы в библиотеке AFNetworking, которая практически всегда и используется. URLSession — это самый низкий уровень, на котором реализованы сетевые запросы. использовать их можно, но это если ты по каким то причинам не можешь работать с нормальными тулзами или просто извращенец. ниже пример POST запроса на AFNetworking
manager.POST(url, parameters: params,
success:
{
(requestOperation, response) in
print("success")
},
failure:
{
(task, error) in
print("error")
}
)
Z>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
Потому что ты не осилил найти библиотеку, видать.
Возвращаясь к свифту. Ты тут привел пример очередной говнобиблиотеки с говно-API. Других в Свифте и не может быть, потому что он не умеет в async/await, а умеет только в спагетти из коллбэков.
Oh wait
— зверюга: «эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны, перекладывание части работы на компилятор и так далее». Свифт — бог, С# говно.
— Lattner: наши коллбэк-API говно, я хочу ввести в язык новые синтаксические конструкции async, await и actor
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Sinclair, Вы писали:
S>>Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass. Z>здесь уже отвеченно тебе же Z>http://rsdn.org/forum/flame.comp/7609323.1
Ну там же опять враньё и передёргивание. Я там ответил.
S>>Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так: Z>хорошо, с этим я согласен. за последними версиями сишарпа я не следил. видимо, сперли у свифта решение (сарказм если что).
Даже без range operator шарп прекрасен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Я в свифте конечно мало что понимаю, но ваш пример явно выглядит на С# лучше, чем на свифте. Есть риск, что если вы продолжите приводить более интересные примеры, то свифт вообще сольёт даже шарпу трёхлетней давности, не то что 8.0.
Справедливости ради, правильный аналог будет таким:
// swift
// guard <condition == true> else { <code> }
// это прямой аналог
// if <condition != true> { <code> }
guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else {
self.authenticationDidFail = true;
}
// строго аналогично
if(!(response is HTTPURLResponse httpResponse && (200..300).Contains(httpResponse.statusCode)) {
self.authenticationDidFail = true;
}
Что все равно приводит к выигрышу Шарпа, потому что ему не нудны никакие дополнительные синтаксические конструкции.
Здравствуйте, IID, Вы писали:
IID>Купил за кеш айфон — и ты больше не нищеброд, а респектабельный платежеспособный господин.
С чего бы? Обычный гаджет.
IID>Applicants with more advanced degrees tend to have higher incomes. Does that mean that those with high incomes are less likely to be video gamers as well? We looked into the percentage of applicants with gaming purchases by income group to find out.
Кому что, а IID опять про игры.
А потом будешь рассказывать что это мы тему переводим.
Здравствуйте, CreatorCray, Вы писали:
CC>Кстати любопытно как поживает и чем теперь занимается автор сего мема.
Пару лет назад совершил огромный прорыв в теоретической физике:
Найдено общее решение системы уравнений ОТО для изотропной Вселенной с плоским пространственным сечением и синхронизируемым временем с учётом идеальной пыли и космологической постоянной. Решения Шварцшильда, Фридмана, Эйнштейна -- де Ситтера, а так же все их объединения друг с другом являются частными случаями найденного общего решения. Найден способ порождения бесконечного количества семейств решений Толменовского типа. Найдены точные решения для пылевого облака в расширяющейся Вселенной заполненной излучением. Выписаны обыкновенные дифференциальные уравнения для пылевого облака во Вселенной заполненной излучением и нерелятивистским газом. Выписана система уравнений описывающая гравитационное поле сферически симметричного ультрарелятивистского взрыва звезды. Обсуждается проблема отрицательной плотности энергии в решениях ОТО и способ как эту проблему обойти.
Здравствуйте, Ватакуси, Вы писали:
В>Что случилось с такой перспективной технологией как .net?
Она утонула.
Война́ станда́ртов — конкурентная борьба между несовместимыми техническими спецификациями систем или устройств за доминирование на рынке. Война стандартов развязывается в начальных периодах развития технологий, когда преимущества тех или иных подходов неочевидны. Часто ей способствует отказ одной из конкурирующих компаний от создания открытого стандарта. Подобные войны характерны для стран с рыночной экономикой, основанной на конкуренции.
Здравствуйте, vsb, Вы писали:
vsb>Моё имхо — линукс окончательно вытесняет венду на серверах. .NET конечно научился чего-то там делать на линуксе, но Java всё равно более надёжный выбор. Плюс у жавы есть огромный рынок андроид-приложений, который в какой-то степени помогает и серверной жаве, у .NET такого рынка нет. Был огромный рынок десктопов, но тут ровно та же ситуация, десктопы стагнируют, а мобильные устройства цветут и пахнут. vsb>ИМХО микрософту нужны убойные технологии. Если ничего крутого на .NET не выстрелит, они уйдут в небытие рано или поздно. Java это хорошая технология, за ней реет дух свободы. Язык, конечно, уступает C# но на практике это не критично, а многие шарперы вообще не в восторге от такой кучи нововведений, т.к. не осиливают их.
Кому хочется языковости берут scala kotlin groovy clojure. Пихать всё в один язык — верная смерть.
А у Явы есть отличный IDE, который код сам за тебя пишет. Читабельность кода (что собственно самое важное в больших долгоиграющих проектах) получается замечательная.
Так что реальных преимуществ у C# никогда и не было, просто очередной NIH-синдром. Я скорее удивляюсь, что он прожил столько.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Z>питон ...
не очень понятно как тут питон затесался в примере про эволюционировать и застывшие Java и C#. в шарпе фичи чаще появляются чем в питоне. питон как-то оживился только на последних минорных версиях тройки. всякие корутины, async-ы причем появились значительно позже того же шарпа (и скорее всего под влиянием оного)
Здравствуйте, BrainSlug, Вы писали:
BS>у чистого питона максимум что было изначально это некий сахар вокруг доступов по индексу и прочему, ничего в этом прям такого вау нет, и уж точно заточенностью под работу с массивами назвать это сложно. потом появились pandas и т.п. но это не язык. это отдельные библиотеки.
ну так аналогично в сишарпе. тот же linq — это всего лишь библиотека, которая дефакто стала стандартом языка (как stl в c++).
какая разница, сахар там или библиотека? если это упрощает жизнь, то чихать я хотел, как это обзывается, если оно доступно из под коробки.
Z>ну так аналогично в сишарпе. тот же linq — это всего лишь библиотека,
linq это не библиотека ни какая а встроенный dsl. Z>какая разница, сахар там или библиотека? если это упрощает жизнь, то чихать я хотел, как это обзывается, если оно доступно из под коробки.
pandas не доступен из коробки, тебе как минимум его нужно установить
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Mamut, Вы писали:
M>>Вообще, .net начинался 20 (!) лет тому назад, как строго windows-only технология в условиях, когда Винде не было и не предвиделось альтернатив.
Z>ты преувеличил немного. 20 лет назад — это 99-ый год (ну почти 0-ой). дотнет появилась в 2002-ом, как счас помню.
Ну так несколько лет до этого шла разработка платформы, языков и компиляторов.
Z>ну и проверку кодов на требуемый диапазон ты тоже упустил. есть конкретные значения, каким боком ты здесь IsSuccess приплел? IsSuccessStatusCode как раз и выполняет проверку на то, что код в диапазоне 200..299
Здравствуйте, IID, Вы писали:
IID>1) Флагманы андроидные не сильно дешевле, а иногда и дороже.
А какая разница девелоперу под ведроид сколько стоит флагман? Его интересует платежеспособность аудитории, для которой он пишет.
IID>А самое главное — какая корреляция между бюджетностью телефона и его отдачей ? IID>Правильно, никакой.
Прямая. Какие аппы там будут хорошо работать а какие не потянет. Ну и в целом платежеспособность/готовность покупать у людей с бюджетными моделями как правило ниже.
IID>Славно пригорело.
Это просто ты не понимаешь о чём рассуждаешь.
IID>Речь о рыночной доле телефонов. И да — доля эпла только снижается.
Пофигу. Интересует денежный выхлоп этой доли.
IID>Причём тут доходы мобильных приложений?
Это доходы разработчиков приложений.
IID>Когда эплобою возразить хочется, но нечем, он начинает хвастаться как качественно его умеют доить.
Пригорает?
У меня всю жизнь ведроид межжупрочим
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, IID, Вы писали:
IID>>1) Флагманы андроидные не сильно дешевле, а иногда и дороже. CC>А какая разница девелоперу под ведроид сколько стоит флагман? Его интересует платежеспособность аудитории, для которой он пишет.
Откуда взялся девелопер ?
Изначальная мысль была что число огрызков стремительно сокращается, и их уже осталось совсем немного.
Собственно откуда взялись ценники-флагманы я тоже не понимаю. Тут уж просто отвечал на попытку Мамута сменить тему.
CC>Прямая. Какие аппы там будут хорошо работать а какие не потянет.
Тем не менее доля эпла падает.
CC>Ну и в целом платежеспособность/готовность покупать у людей с бюджетными моделями как правило ниже.
Неверно. Я уже писал про исследование рынка игр. Как раз небогатые люди с далеко не топовыми компами платили больше всего.
IID>>Славно пригорело. CC>Это просто ты не понимаешь о чём рассуждаешь.
Да это вы тему сменить пытаетесь.
То что в эпле сильнее доят юзеров — факт. Может это и есть причина сокращения доли эпла ?
IID>>Речь о рыночной доле телефонов. И да — доля эпла только снижается. CC>Пофигу. Интересует денежный выхлоп этой доли.
Меня не интересует.
IID>>Причём тут доходы мобильных приложений? CC>Это доходы разработчиков приложений.
Откуда взялись разработчики мы так и не выяснили.
IID>>Когда эплобою возразить хочется, но нечем, он начинает хвастаться как качественно его умеют доить. CC>Пригорает? CC>У меня всю жизнь ведроид межжупрочим
А это я не тебе отвечал, ты тут в разговор вклинился. Впрочем у тебя свой мотив есть, вступиться за работодателя, шоп не обижали.
Здравствуйте, CreatorCray, Вы писали:
IID>>Собственно откуда взялись ценники-флагманы я тоже не понимаю. CC>Ты поди в плоском виде форум читаешь и веток обсуждения не видишь?
Я написал утверждение про количество устройств. Ценники-флагманы уже вы зачем-то в ответ притащили, чтобы тему замылить.
CC>>>Ну и в целом платежеспособность/готовность покупать у людей с бюджетными моделями как правило ниже. IID>>Неверно. Я уже писал про исследование рынка игр. Как раз небогатые люди с далеко не топовыми компами платили больше всего. CC>Эк ты сову растянул то! CC>Осталось ещё исследование погоды на Марсе приложить и тогда всё станет понятно каким боком игры на нетоповых компах к доходам разработчиков мобильных аппов.
Ты придуриваешься ?
Речь о платежеспособных юзерах. Которые ВНЕЗАПНО не коррелируют с ценой девайса. Откуда опять разработчики взялись ?
IID>>>>Причём тут доходы мобильных приложений? CC>>>Это доходы разработчиков приложений.
И эпла...
Да насрать на них. Не о них речь.
IID>>Откуда взялись разработчики мы так и не выяснили. CC>Ветку то перечитай наконец. Она началась с фразы "В последнее время выстрелили мобильные предложения. А там рулит Ява."
Конкретно эта подветка началась с обсуждения числа девайсов
Здравствуйте, Mamut, Вы писали:
AA>>Эволюция ограничена первоначальными установками. Яркий пример — записи, AA>>то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.
M>Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое.
Подозреваю, что речь как раз про
public (string Name, int age) Foo()=> ("Hello", 42);
Которые там куда-то не могут завести
AA>>есть Color c; AA>>Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);
M>Не обязательно чище. Паттерн матчинг даже в урезанном виде — очень мощная штука, в которой главная мощь — это то, что ты можешь матчить и по значениям и по типам. Даже в твоем примере если матчить только по одному значению, то проще if. А если по нескольким? А если по нескольким условиям? А если по нескольким типам и условиям?
+1. Опять же, тут только что рядом фанаты шарпа показывали, как можно совершенно прямолинейный код выписать в совершенно противоестественном виде — через Enumerable.Range().ToArray() и так далее.
Ну так в нормальной-то обстановке всё ровно наоборот: пишут самый короткий и понятный код, а не самый длинный и дурацкий. Не будет никто деконструкцию делать, когда можно просто вычислить c.Red == 255.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Z>ты в своем уме? никто тебе не мешает делать эту проверку
О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор. Ну то есть необходимость guard'а стала вообще нулевая.
Но уровень развития языка, кончено, забавляет.
Z>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль
То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.
Z>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно
«В зависимости от ситуации», «то, что нужно», «нет, это в других языках эволюция путем нагромождения функционала и ненужных конструкций, свифт не такой»
M>>Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.
Z>ну это вообще капец. оказывается, что лучше использовать фильтр, чем просто lete Z>
Z>x.filter(x => x > 10).orElseThrow(...) // тут еще проверки на нуль не хватает
Z>
orElse/orElseThrow — это уже проверка на нуль.
Z>let и guard Z>1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок Z>2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется
Итого, и let и guard делают одно и тоже, но при этом две конструкции. Одна из них явно лишняя.
Что самое смешное, что любые статьи и любая документация про guard прямо из кожи вон лезет, чтобы пытаться доказать, что guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.
Z>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение
А да. Ведь магический гард этого никогда не делает, ты что:
guard let httpResponse = response as? HTTPURLResponse,
(200...299).contains(httpResponse.statusCode) else
Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.
Здравствуйте, zverjuga, Вы писали:
Z>>>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему? M>>Потому что ты не осилил найти библиотеку, видать. Z>я не нашел. может ты найдешь?
А чем какой-нибудь okhttp не устраивает? А ещё есть retrofit, volley, Android-Async-Http и прочее хипстерство.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Mamut, Вы писали:
Z>>ты в своем уме? никто тебе не мешает делать эту проверку
M>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор.
если у тебя xcode со времен динозавров, то возможно. но такой проблемы не было никогда, начиная с самых первых версий свифта. боюсь, что ты чего то не договариваешь. или не разобрался тогда. я по крайней мере не пропомню, когда у меня была такая проблема, правда я со свифтом начал работать около 4 лет назад только.
Z>>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль M>То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.
это все потому что свифт поддерживается парадигмы строгой типизации. он не допускает своевольничания и предположений. если тип оптионал, то ты обязан перед тем, как работать со значением, его извлечь. при этом оператор принудительного извлечения ! не является безопасным, и ты вполне можешь получить исключением, если попытаешься что то извлечь из нуля. строгая типизация она да, такая. и использование просто IF не дает тебе гарантии, что ! не выдаст тебе исключения
Z>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно
M>orElse/orElseThrow — это уже проверка на нуль.
а он разве не сработает после вызова метода filter? а ведь нужно — до
и лучше использовать фильтр, чем let, я это уже понял.
M>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.
guard НЕ МЕНЯЕТ тип переменной. он (вернее не он, а let) создает НОВУЮ КОНСТАНТУ в которую копируется безопасное извлечение из оптионала. то есть, чтобы было понятнее
guard let y = x else {
}
или
if let y = x {
}
создается новая КОНСТАНТА y, которая инициализируется значением из оптионала x. примеры выше были такими
guard let x = x else {
}
x.foo() // здесь X уже не тот X, который был ранее. это новая константа
и таки да, свифт позволяет делать такие вещи, чтобы не плодить лишних имен. это обычное замещение переменной, когда новое имя перебивает старое. ты волен выбирать, как тебе удобнее, так или сяк.
M>>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор. Z>если у тебя xcode со времен динозавров, то возможно
Поставлен сразу на новую Каталину.
Z>это все потому что свифт поддерживается парадигмы строгой типизации. он не допускает своевольничания и предположений.
Ага, и гард своевольничает и предполагает: вводит новые переменные в scope и переназначает типы переменным.
Z>если тип оптионал, то ты обязан перед тем, как работать со значением, его извлечь. при этом оператор принудительного извлечения ! не является безопасным, и ты вполне можешь получить исключением, если попытаешься что то извлечь из нуля. строгая типизация она да, такая. и использование просто IF не дает тебе гарантии, что ! не выдаст тебе исключения
Да неужели? Правда, что ли? В жизни никогда не подумал бы!
Это был сарказм, если что. guard для этого не нужен, от слова совсем.
Z>>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно M>>orElse/orElseThrow — это уже проверка на нуль. Z>а он разве не сработает после вызова метода filter? а ведь нужно — до
Нет, не сработает. Нет, не нужно. Более того, Свифту даже до уровня Optional'ов в Java — как из Парижа до Пекина на карачках.
Z>guard НЕ МЕНЯЕТ тип переменной. он (вернее не он, а let) создает НОВУЮ КОНСТАНТУ в которую копируется безопасное извлечение из оптионала. то есть, чтобы было понятнее
То есть чтобы было понятнее: Swift — единственный в мире язык со «парадигмой строгой типизации, который не допускает своевольничания и предположений», в котором переменная внутри scope'а меняет тип в зависимости от того, участвовала она внутри присваивания в определенной конструкцией или не участвовала.
Ни у одной другой конструкции в языке нет такого функционала. Как ты там говорил? Упрощние синтаксиса? Не надо нагромождать функционал и ненужные синтаксические конструкции? Бугагага
Z>и таки да, свифт позволяет делать такие вещи, чтобы не плодить лишних имен. это обычное замещение переменной, когда новое имя перебивает старое. ты волен выбирать, как тебе удобнее, так или сяк.
Это не обычное замещение имен. Это смена типа переменной. С Optional<T> на T. Но великому прекрасному статически типизированному языку без своевольничания и предположений это почему-то невдомек.
Здравствуйте, Ватакуси, Вы писали:
C0x>>А с чего ты взял что у .net падение популярности?
В>Даже в первую десятку не входит по популярности запросов Гугл.
А подтверждения этого утверждения есть? TIOBE уже привели, есть еще PYPL index, который строится на популярности запросов в Гугл:
The PYPL PopularitY of Programming Language Index is created by analyzing how often language tutorials are searched on Google.
Там C# — 4-й.
В>Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET. Это 3 банка из первый пятёрки и очень крупные мировые программерские конторы. Так же гос. учереждения (размером с министерство) в странах ЕС.
Ну это субъективный опыт на основании которого нельзя делать выводы. Я слышал и противоположные мнения.
Здравствуйте, Ватакуси, Вы писали:
В>Ешё 5 лет назад он был на коне, нам рассказывали, что ява-вот вот окочурится, а сегодня на .net уже крупняк не пишет почти, а все мелкие только дописывают, что у них осталось.Я В>Ява же — живее всех живых и даже пополнела.
В>Что случилось с такой перспективной технологией как .net?
В принципе core может придать второе дыхание, но в целом из-за потери мобильного рынка ms, в которой доля .net могла вырасти в разы, случилась если не стагнация, то
застой. Вроде сейчас делают разумные, и я очень надеюсь успешные, попытки выхода для мишинного обучения -- .net core для jupyter, ml.net.
C>виртуалки на linux на ура захватывают сетевое пространство, NET нуда не вмещается, mono несколько лет назад был поделкой на коленке, уже выросло новое поколение программистов, кому этот NET не уперся.
.net туда прекрасно вмещается. У нас половина микросервисов на .net core
В>Ешё 5 лет назад он был на коне, нам рассказывали, что ява-вот вот окочурится, а сегодня на .net уже крупняк не пишет почти, а все мелкие только дописывают, что у них осталось.Я
пишут В>Ява же — живее всех живых и даже пополнела.
живее, все живых, да В>Что случилось с такой перспективной технологией как .net?
долго на винде засиделись, пока другие облачные и мобильные рынки осваивали. потом правда одумались и появился .net core.
Z>он засветился, потому что очень классно заточен для работы с массивами и строками, прям загляденье.
а ты можешь писать не эпитетами ("классно, загляденье") а конкретными вещами?
у чистого питона максимум что было изначально это некий сахар вокруг доступов по индексу и прочему, ничего в этом прям такого вау нет, и уж точно заточенностью под работу с массивами назвать это сложно. потом появились pandas и т.п. но это не язык. это отдельные библиотеки.
Z>>много чего. поработай с ним и поймешь. BS>ну понятно, тайные знания они такие тайные.
из раза в раз надоело повторять одни и те же примеры, а я в подобных темах уже их приводил. к тому де заранее известны твои аргументы, так как тоже не первый раз. а именно то, что все то, что есть в свифте, есть и в сишарпе (ну за исключением некоторых синтактических нюансов). но дело не в том, что они есть, а как их использовать. в свифте это проще и нагляднее, меньше кода, меньше писанины.
потому, просто изучи и поработай с новыми языками, тогда поймешь.
Здравствуйте, zverjuga, Вы писали:
Ф>>Правильно говорить "синтаксический оверхед". Ф>>UPD: да-да, с перасходом строчек кода
Z>да, то что я и хотел сказать. после того, как поработаешь с тем же свифтом, переходить обратно на сишарп — это пипец мучение.
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Mamut, Вы писали:
Z>причем тут? где ты его в примере вообще увидел? откуда ты знаешь, как ты вообще получил? Z>ну и ты тоже упустил.
Неразумно спорить о мелких деталях синтаксиса.
Можешь хотя бы в нескольких пунктах сформулировать, чем свифт лучше? Ну, например, шарп лучше некоторого условного языка Х тем, что
есть async/await и не надо колбеки с конечными автоматами руками писать
есть линк и можно писать типизированные запросы ко внешним источникам данных, в частности к реляционным БД
есть возможность обобщенно и безопасно работать с областями памяти разного типа — на стеке и т.д., что дает возможность перфоманс оптимизировать
M>ага. какой-то сферовакуумный код, в котором неизвестно откуда взявшийся response внезапно надо срочно привести к HTTPURLResponse. Нет конечно. Все это — результат убогого до невозможности API Свифта (что ты там ныл про отсутсвие «нормальных асинхронных HTTP API в Андроиде»?)
Но тут ты сам взял вбросил какой-то говнокод и на его основе начал хаять язык.
К тому же ты зачем-то обсуждаешь API операционки, а пытаешься создать вид, что проблема в языке
M> // а проверить на nil через if x == nil в общем случае нельзя. M> if let error = error {
чушь и неправда
M> // жрем еще говна прекрасным дизайном API M> // потому что согласно зверюге, в красивом API ответ от M> // хттп-клиента может быть чем угодно, например, AnyObject
бред. речь шла о языке, ты нафига-то притянул сюда API операционки. есть нормальные библиотеки, в стиле swift
M> // почему так? Потому что убогое убожество Swift M> // неспособно привести одно к другому, а из него достать третье M> // у response тип URLResponse? поэтому надо привести к HTTPURLResponse? через as? M> // а через что же еще. Больше! Больше доп. синтаксиса! Это не как в C#/Java, это другое
больше демагогии и говнокода в качестве примера дерьмовости языка
M> // и надо его сначала "unwrap" через ! (аналог .get() в Java) M> // и результат тоже Optional. Его тоже надо распаковать!
нет, просто надо нормально писать код. у меня в проектах линтер настроен на блокировку force unwrapping, и совершенно не портит жизнь.
Здравствуйте, zverjuga, Вы писали:
SD>>ну не обязательно же данные тебе языком возможности использовать в таком уродском виде
Z>это отличный пример, который нужно переписать на сишарп или джаву, чтобы увидеть разницу между свифтом и сишарпом-джавой.
Не уверен, что до конца понял пример, но попробую.
M>>guard let httpResponse = response as? HTTPURLResponse, M>> (200...299).contains(httpResponse.statusCode) else { M>> DispatchQueue.main.async { M>> self.authenticationDidFail = true; M>> } M>> return M>> }
if (response instanceof HTTPURLResponse) {
var httpResponse = (HTTPURLResponse) response;
if (!(200 <= httpResponse.statusCode && httpResponse.statusCode <= 299)) {
DispatchQueue.main.async(() -> {
authenticationDidFail = true;
});
return;
}
}
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Mamut, Вы писали:
M>>Вот пример C#:
Z>он не соответствует исходному примеру.
Z>1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность
Это в C# делается вот так:
if(response is HTTPURLResponse httpResponse)
Z>2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode
Это делается через Range operator 200..300. (Ranges в C# — end-exclusive).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, zverjuga, Вы писали:
Z>>Здравствуйте, Mamut, Вы писали:
M>>>Вот пример C#:
Z>>он не соответствует исходному примеру.
Z>>1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность S>Это в C# делается вот так: S>
S>if(response is HTTPURLResponse httpResponse)
S>
Z>>2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode S>Это делается через Range operator 200..300. (Ranges в C# — end-exclusive).
и по итогу получается вот так
if (response is HTTPURLResponse httpResponse) {
if (!Range(200...3000).Contains(httpResponse.statusCode) {
self.authenticationDidFail = true;
}
}
else {
self.authenticationDidFail = true;
}
когда в оригинальной версии было
guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { // перенес в одну строчку, чтобы было наглядно, что это часть конструкции guard let, аналог AND (&&) в сишарпе
self.authenticationDidFail = true; // этот код работает, когда response НЕ является HTTPURLResponse ИЛИ statusCode не входит в заданный диапазон
}
я уже говорил, что я не утверждаю, что в сишарпе нельзя сделать того, что можно сделать в свифте. не нужно мне отдельные куски показывать, нужно показать пример целиком, чтобы была видна разница. и уже говорил, что прекрасно знаю, как продолжаются и заканчиваются подобные срачи. нет смысла дискутировать, пока оппонент не будет знать предмета разговора. то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, zverjuga, Вы писали:
Z>>>Здравствуйте, Mamut, Вы писали:
M>>>>Вот пример C#:
Z>>>он не соответствует исходному примеру.
Z>>>1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность S>>Это в C# делается вот так: S>>
S>>if(response is HTTPURLResponse httpResponse)
S>>
Z>>>2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode S>>Это делается через Range operator 200..300. (Ranges в C# — end-exclusive).
Z>и по итогу получается вот так Z>
Z>guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { // перенес в одну строчку, чтобы было наглядно, что это часть конструкции guard let, аналог AND (&&) в сишарпе
Z> self.authenticationDidFail = true; // этот код работает, когда response НЕ является HTTPURLResponse ИЛИ statusCode не входит в заданный диапазон
Z>}
Z>
Тебе привели пример страницу назад, а ты все еще копротивляешься?
Z>ну раз ты настаиваешь, чтобы эту глупость прокомментировал, то изволь. Z>асинхронные http(s) вызовы в свифте еще сто лет назад были реализованы в библиотеке AFNetworking
Ну то есть ты наезжаешь на Java, что там нет «красивого асинхронного API». Как говоришь, что в Свифте API говно, ВНЕЗАПНО выясняется, что надо всего лишь найти библиотеку?
Ну и у кого глупость?
Это не говоря о том, что лапша из коллбэков считается плохим тоном в программировании уже оооочень давно. Неудивительно, что Lattner собирается вводить в язык async/await.
Ее ты не видишь. Код на C# делает немного не то, что Свифт. Решается добавлением ровно одного ! безо всяких else А так синтаксис практически один в один, но только без лишнего нагромождения ненужных синтаксических конструкций в виде guard.
guard в свифте существует ровно по одной причине: вместо того, чтобы «убрать синтаксические нагромождения, которые не нужны, и переложить части работы на компилятор» по твоим заветам, авторы свифта не осилили переложить на компилятор проверку на nil. То есть они не осилили ни полноценную проверку на nil (что можно делать if'ом), ни более-менее полноценный Optional (можно не такой, как в Haskell'е, но хотя бы как в Rust'е).
Поэтому они сделали половинчатое решение, придумав абсолютно бессмылсенную и ограниченную во всех смыслах конструкцию, которая даже в простебйших примерах выглядит, как говно (потому что и есть говно).
Здравствуйте, Mamut, Вы писали:
Z>>я не нашел. может ты найдешь?
M>Зачем? Ты же будешь считать, что библиотека — говно, потому что там, например, не божественный `(200...299).contains` а богомерзкий `(200..300).Contains` или что-то в этом же роде.
нет не буду. я хочу посмотреть, как в андроиде под джавой делаются удобные http(s) запросы на сервер. я как то упомянул, что в андроиде это по каким то причинам не реализовано, ты эту тему начал развивать. только запросы, никаких отдельных contains (правда ты пропустил Range(2000...300), против свифтового (200...300)) я сравнивать не буду, так как это тема для отдельных подветок.
Здравствуйте, Mamut, Вы писали:
Z>>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль M>То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.
Тем временем, взрослый компилятор, естественно, не должен заставлять учить магию типа guard let x = x Z>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно
Z>>let и guard Z>>1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок Z>>2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется M>Итого, и let и guard делают одно и тоже, но при этом две конструкции. Одна из них явно лишняя.
M>Что самое смешное, что любые статьи и любая документация про guard прямо из кожи вон лезет, чтобы пытаться доказать, что guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.
Z>>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение
Тем временем, драфт спеки C# 8.0 обещает nullability tracking "таким же образом, как мы отслеживаем definite assignment".
То есть никакой распаковки в новую переменную не требуется, как и магии с x = x:
public static int Foo(string? firstName, string? lastName)
{
if(firstName == null) throw new ArgumentException(nameof(firstName));
return
firstName.Length + // здесь warning-а нету: firstName is non-null
lastName.Length + // а здесь - есть.
1;
}
То есть обычный if, будучи правильно реализован, прекрасно справится с "избавить от дополнительных проверок".
Не знаю, смогут ли это же докрутить до Nullable<T> типов, но было бы логично.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор
ты уже несколько раз повторил эту мантру про nil и ни разу не удосужился проверить это на актуальной версии языка? хоть бы на том же самом repl.it
M>- у нас внезапно добавляется новый ненужный синтаксис (да еще и дико кривой: guard <condition> else {} вместо хотя бы guard <condition> {}) M>guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.
guard не что-то прям особенное, просто наверное ты его не использовал на практике вот он для тебя как-то дико выглядит. И поэтому ты сделал вон то "странное" предложение с убиранием "else". Синтаксис guard сделан так, чтобы программа читалась как текст, а не набор символов пунктуации. По сути его можно было назвать ассертом: нужно [утверждение] иначе [аварийное действие]
guard let ad = post as? AdPost else { return }
guard books.amount > 0 else { return nil }
Читается как "должно быть книг.количество больше нуля, иначе результат – пустота"
Z>>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение M>А да. Ведь магический гард этого никогда не делает, ты что:
guard и if схожи, у них главное отличие: if-let создаёт поле внутри блока if, а guard-let создаёт это поле до конца текущего скоупа. При этом let там не обязателен, можно простое условие, без создания поля.
M>guard let httpResponse = response as? HTTPURLResponse, M> (200...299).contains(httpResponse.statusCode) else M>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.
Что значит "на ровном месте меняет"? Автор кода явно задекларировал "допустим response это HTTPURLResponse", всё меняется как запланировано, точнее не меняется а создаётся новое поле с указанным типом.
Хотя мне в свисте очень не хватает смарт кастинга котлина:
if (response !is HttpResponse || response.statusCode !in 200..299)
return
// тут response имеет тип HttpResponse и statusCode находится в диапазоне [200..299]
SD> ты уже несколько раз повторил эту мантру про nil и ни разу не удосужился проверить это на актуальной версии языка? хоть бы на том же самом repl.it
Поставил свежую Каталину. Поставил на нее свежий XCode (на момент установки Каталины). Получил то, что получил.
Ах, надо было обновиться на версию, которая, видать, толкьо вчера вышла? Ну извиняйте.
И тем более, раз можно if x == nil, то смысл иметь в языке guard исчезает напрочь.
SD>guard не что-то прям особенное,
я нигде не говорю, что он что-то особенное. это утверждает зверюга. Я говорю прямым текстом, чем оно является: ненужной дополнительной кастрированной версией if'а.
SD>просто наверное ты его не использовал на практике вот он для тебя как-то дико выглядит. И поэтому ты сделал вон то "странное" предложение с убиранием "else". Синтаксис guard сделан так, чтобы программа читалась как текст, а не набор символов пунктуации.
guard сделан так, чтобы потом надо было тратить много страниц текста на объяснение, наига он нужен, и чем он отличается от if'а. Рационализация этого костыля слаба. И «программа должна читаться как текст» очень смешно выглядит в контексте практически любого языка в общем, и в С-синтаксисе Свифта в целом.
SD>По сути его можно было назвать ассертом: нужно [утверждение] иначе [аварийное действие]
Нельзя было.
SD>Читается как "должно быть книг.количество больше нуля, иначе результат – пустота"
Ну то есть читается, как if.
M>>А да. Ведь магический гард этого никогда не делает, ты что: SD>guard и if схожи, у них главное отличие: if-let создаёт поле внутри блока if, а guard-let создаёт это поле до конца текущего скоупа. При этом let там не обязателен, можно простое условие, без создания поля.
Итак, на ровном месте создали, согласно зверюге «доп функционал и нагромождение синтаксиса», которое не нужно даже даром (при наличие внятного компилятора, понятное дело).
Потому что то, что ты написал ровно ничем не отличается от банального if'а. Чем guard и является.
M>>guard let httpResponse = response as? HTTPURLResponse, M>> (200...299).contains(httpResponse.statusCode) else M>>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной. SD>Что значит "на ровном месте меняет"? Автор кода явно задекларировал "допустим response это HTTPURLResponse", всё меняется как запланировано, точнее не меняется а создаётся новое поле с указанным типом.
Ты не в том месте разорвал цитату. зверюга утверждал, что другие языки говно, потому что надо вводить временные переменные. Хотя прекрасно видно, что guard легко вводит временные переменные.
Вдобавок. В отличие от любых (?) других конструкций, эти временные переменные появляются не внутри гарда, а внутри всей области видимости, где находится этот гард. Удобно, чо. Главное, единообразно, ага.
А можно сделать вот так:
Было:
let response : URLResponse? = ....
// обязаны использовать as? потому что
// response имеет тип URLResponse?
self.token = (response as? HTTPURLResponse).value
Стало:
let response : URLResponse? = ....
guard let response = response else {
return
}
// response поменял тип на URLResponse
self.token = (response as? HTTPURLResponse).value
Отличный, замечательный язык.
SD>Хотя мне в свисте очень не хватает смарт кастинга котлина: SD>if (response !is HttpResponse || response.statusCode !in 200..299)
M>guard сделан так, чтобы потом надо было тратить много страниц текста на объяснение
ну не все могут понимать лаконичную документацию языка, этим разжёвывают, да 🙂
SD>>Хотя мне в свисте очень не хватает смарт кастинга котлина: SD>>if (response !is HttpResponse || response.statusCode !in 200..299)
M>Или сишарпа
Пример, который мы обсуждаем, как мы уже увидели, в C# в реальности выглядит так:
var response = await httpClient.GetAsync(url);
if (!response.IsSuccessStatusCode){
<вызов любого async кода>
return;
}
Во-первых, никаких «заставляет вникать в логику». Во-вторых никаких кривых дополнительных конструкций. В-третьих, код, до которого Свифту, как до Пекина раком (хотя await таки хотят вводить).
Еще раз: guard не является ничем иным, как убогой урезанной версией if'а, на которую еще нагромодили доп. функционал: вводит новые переменные в scope, переопределяет тип существующих переменных. То есть ровно то, что ты называешь плохим в других языках.
Здравствуйте, CreatorCray, Вы писали:
B>>так вот, большинство выбирает huawei CC>Огласите весь список пожалуйста.
Интересно, зачем ?
1) ты считаешь что там не будет Apple ?
2) или что там будут только одни huawei
ЗЫ: из имеющихся у меня порядка 40+ девайсов 2013-2018 годов, самые приятные впечатления действительно от хуавеев. Эпл, правда, представлен только 6 и 7 моделью.
У самсунгов одни из самых клёвых экранов. Но совершенно отвратительный процесс разработки (за изничтожение fastboot их вообще на кол посадить надо).
А с гуглофонами (в т.ч. корнями из HTC/Motorola/Huawei) и сони приятнее всего работать.
Здравствуйте, IID, Вы писали:
IID>Игры — основная масса доходов с пользователей.
Тогда почему ты рассказываешь про исследования Video gaming а не Mobile gaming?
Здравствуйте, Mamut, Вы писали:
M>Java эволюционирует медленнее потому что у нее гораздо больше груз обратной совместимости.
Неа. С# до сих пор на 100% backward compatible (за исключением некоторых очень тонких моментов). Java эволюционировала медленно сначала из-за старпера Гослинга, а потом в силу того что у шарпа решения принимает сравнительно маленький language design team, а в Java этот процесс вовлекает большое количество народу.
Здравствуйте, Sinclair, Вы писали:
S>То есть никакой распаковки в новую переменную не требуется, как и магии с x = x: S>
S>public static int Foo(string? firstName, string? lastName)
S>{
S> if(firstName == null) throw new ArgumentException(nameof(firstName));
S> return
S> firstName.Length + // здесь warning-а нету: firstName is non-null
S> lastName.Length + // а здесь - есть.
S> 1;
S>}
S>
public static int Foo(string? firstName, string? lastName) =>
firstName == null
? throw new ArgumentException(nameof(firstName));
: firstName.Length + // здесь warning-а нету: firstName is non-null
lastName.Length + // а здесь - есть.
1;
Здравствуйте, zverjuga, Вы писали:
Z>асинхронные http(s) вызовы в свифте еще сто лет назад были реализованы в библиотеке AFNetworking, которая практически всегда и используется. URLSession — это самый низкий уровень, на котором реализованы сетевые запросы. использовать их можно, но это если ты по каким то причинам не можешь работать с нормальными тулзами или просто извращенец. ниже пример POST запроса на AFNetworking
Ты даже не представляешь в какую жопу превращается этот закат continuation monad вручную, когда уровень вложенности становится больше 1.
Ешё 5 лет назад он был на коне, нам рассказывали, что ява-вот вот окочурится, а сегодня на .net уже крупняк не пишет почти, а все мелкие только дописывают, что у них осталось.Я
Ява же — живее всех живых и даже пополнела.
Что случилось с такой перспективной технологией как .net?
Здравствуйте, Ватакуси, Вы писали:
В>Ешё 5 лет назад он был на коне, нам рассказывали, что ява-вот вот окочурится, а сегодня на .net уже крупняк не пишет почти, а все мелкие только дописывают, что у них осталось.Я В>Ява же — живее всех живых и даже пополнела.
В>Что случилось с такой перспективной технологией как .net?
В последнее время выстрелили мобильные предложения. А там рулит Ява.
Здравствуйте, Socrat, Вы писали: S>А под iOS .NET?
Дотнет есть даже под самсунговские телевизоры и Raspberry Pi, не говоря уже о Windows, Linux, Mac, Android и iOS...
Здравствуйте, Socrat, Вы писали:
S>Здравствуйте, Ватакуси, Вы писали:
S>В последнее время выстрелили мобильные предложения. А там рулит Ява.
уже не рулит
Ява на мобилках теряет актуальность, через год будет только легаси на яве, все новые проекты будут на своих языках платформы.
C>>виртуалки на linux на ура захватывают сетевое пространство, NET нуда не вмещается, mono несколько лет назад был поделкой на коленке, уже выросло новое поколение программистов, кому этот NET не уперся.
M>.net туда прекрасно вмещается. У нас половина микросервисов на .net core
> Initial release June 27, 2016; 3 years ago[1]
этим всё сказано, лавинообразный рост отрасли был в 2013-2015 гг.
возьмите образовательные ресурсы и найдите на них C#, он только в геймдеве представлен.
S>В последнее время выстрелили мобильные предложения. А там рулит Ява.
только на андроиде и то, это скорее легаси, новые проекты стремятся делать на kotlin, и если имеет смысл переводить старые на котлин
Z>да, то что я и хотел сказать. после того, как поработаешь с тем же свифтом, переходить обратно на сишарп — это пипец мучение.
а что там такого в Swift отчего потом мучения в C#?
S>застой. Вроде сейчас делают разумные, и я очень надеюсь успешные, попытки выхода для мишинного обучения -- .net core для jupyter, ml.net.
рано говорить про успшность. kernel для jupyter они вообще выпустили чуть ли не намедни (для Java и Scala уже были) и имхо это не та ниша которую они могут вот так просто выпустив какой-то возможность в ноутбуках писать код, занять. питон с его кучей библиотек, эту нишу прочно занял (причем просто даже hello world примеры по Data Science и Machine Learning показывают не в пользу ml.net, я уж молчу что они там постоянно меняют все от версии к версии), а ниша где как раз и логичен был бы .net как альтернатива jvm с его Java и Scala, — обработка big data и некий workflow ml с конкурентами spark-ов и иже с ними, не наблюдается.
Z>из раза в раз надоело повторять одни и те же примеры, а я в подобных темах уже их приводил. к тому де заранее известны твои аргументы,
что ты мелешь? на историю моих сообщений посмотри, меня тут почти не бывает, а больше года я вообще на форуме не был
Z> так как тоже не первый раз. а именно то, что все то, что есть в свифте, есть и в сишарпе (ну за исключением некоторых синтактических нюансов). но дело не в том, что они есть, а как их использовать. в свифте это проще и нагляднее, меньше кода, меньше писанины. Z>потому, просто изучи и поработай с новыми языками, тогда поймешь.
да понятно уже все, что конкретики не будет, ок
S>>застой. Вроде сейчас делают разумные, и я очень надеюсь успешные, попытки выхода для мишинного обучения -- .net core для jupyter, ml.net. BS>рано говорить про успшность. kernel для jupyter они вообще выпустили чуть ли не намедни (для Java и Scala уже были) и имхо это не та ниша которую они могут вот так просто выпустив какой-то возможность в ноутбуках писать код, занять. питон с его кучей библиотек, эту нишу прочно занял (причем просто даже hello world примеры по Data Science и Machine Learning показывают не в пользу ml.net,
Питон все-таки не то, да и не эффективен (GIL). Но входить в него проще, да. Я был бы очень рад нормально инфраструктуре .net в мире ML. Очень бы там linq помог вместо pandas, например.
BS> я уж молчу что они там постоянно меняют все от версии к версии), а ниша где как раз и логичен был бы .net как альтернатива jvm с его Java и Scala, — обработка big data и некий workflow ml с конкурентами spark-ов и иже с ними, не наблюдается.
Тут соглашусь, почему нет аналога hadoop'а на чистом .net не ясно, адаптеры, наверное, есть, а вот аналогичного фреймворка нет.
Здравствуйте, Sharov, Вы писали:
S>Здравствуйте, BrainSlug, Вы писали:
S>>>застой. Вроде сейчас делают разумные, и я очень надеюсь успешные, попытки выхода для мишинного обучения -- .net core для jupyter, ml.net. BS>>рано говорить про успшность. kernel для jupyter они вообще выпустили чуть ли не намедни (для Java и Scala уже были) и имхо это не та ниша которую они могут вот так просто выпустив какой-то возможность в ноутбуках писать код, занять. питон с его кучей библиотек, эту нишу прочно занял (причем просто даже hello world примеры по Data Science и Machine Learning показывают не в пользу ml.net,
S>Питон все-таки не то, да и не эффективен (GIL). Но входить в него проще, да. Я был бы очень рад нормально инфраструктуре .net в мире ML. Очень бы там linq помог вместо pandas, например.
BS>> я уж молчу что они там постоянно меняют все от версии к версии), а ниша где как раз и логичен был бы .net как альтернатива jvm с его Java и Scala, — обработка big data и некий workflow ml с конкурентами spark-ов и иже с ними, не наблюдается.
S>Тут соглашусь, почему нет аналога hadoop'а на чистом .net не ясно, адаптеры, наверное, есть, а вот аналогичного фреймворка нет.
пока net сидел на windows-only, microsoft потеряла поколение программистов, так что не будет ни хадупа на net, ни net в ML, если кто бабла не вольет
M>>.net туда прекрасно вмещается. У нас половина микросервисов на .net core
>> Initial release June 27, 2016; 3 years ago[1] C>этим всё сказано, лавинообразный рост отрасли был в 2013-2015 гг.
Что сказано?
C>возьмите образовательные ресурсы и найдите на них C#, он только в геймдеве представлен.
И? Из того, что на образовательных ресурсах C# представлен в геймдеве, я должен делать какие-то далеко идущие выводы? Я моуг взять, например, Google Cloud. Ой, ты посмотри. C#/.Net среди платформ, которые напрямую поддерживаются Гуглом. Этот показатель гораздо лучше, чем «ой, на курсере C# только для игр».
Здравствуйте, Calc, Вы писали:
S>>Тут соглашусь, почему нет аналога hadoop'а на чистом .net не ясно, адаптеры, наверное, есть, а вот аналогичного фреймворка нет. C> так что не будет ни хадупа на net, ни net в ML, если кто бабла не вольет
Увы, похоже на то. На счет денег -- ну кто кроме самой мс вольет денег?...
M>>Или вот эти прекрасные конструкции: M>>guard let httpResponse = response as? HTTPURLResponse, <...>
SD>ну не обязательно же данные тебе языком возможности использовать в таком уродском виде
Это напрямую пример то ли из документации, то ли из какого-то примера (потому что и с тем и с другим у Свифта полных швах).
1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность
2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode
Он полностью ему соответсвует. То, что Swift не осилил внятный API для HTTP-клиента, это проблема криворукости его разработчиков. Там вообще весь Foundation это яркий пример того, как делать не надо. Чтение и запись файлов я показывал, да.
Здравствуйте, Mamut, Вы писали:
Z>>он не соответствует исходному примеру.
M>Он полностью ему соответсвует. То, что Swift не осилил внятный API для HTTP-клиента, это проблема криворукости его разработчиков. Там вообще весь Foundation это яркий пример того, как делать не надо. Чтение и запись файлов я показывал, да.
причем тут hhtpClient? где ты его в примере вообще увидел? у тебя есть response непонятного типа, который должен быть приведен к HTTPURLResponse + проведена проверка. откуда ты знаешь, как ты вообще этот response получил? это может быть параметр в функции типа AnyObject.
ну и проверку кодов на требуемый диапазон ты тоже упустил. есть конкретные значения, каким боком ты здесь IsSuccess приплел?
Z>кстати, отличный пример. попробуешь переписать подобное в сишарпе?
Какие-то непонятки с типами as?. Глобальные переменные "DispatchQueue.main". И непонятно кто такой self.
На java будет что-то типа
if (!response.isSuccessful()) {
//послать сообщение в очередь? Или я не понял что там делается?
queue.add(new AuthenticationDidFail (true));
}
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, TimurSPB, Вы писали:
S>>>В последнее время выстрелили мобильные предложения. А там рулит Ява. TSP>>В геймдеве популярен Unity. А там C#
CC>Для сравнительно небольших проектов. Потом упираются в ресурсы.
Здравствуйте, zverjuga, Вы писали:
Z>переписанный код на сишарпе будет таким
Z>var foo = someObject as ConcreteClass; Z>var array = Enumerable.Range(200, 299).ToArray();
Зачем тут .ToArray()?
Z>if (foo == null || !array.Contains(foo.someValue)) { Z> // запустить в главном потоке код
А в каком он по твоему запустится?
Z> // self.authenticationDidFail = true Z>}
Z>я уже и не помню, как в сишарпе одной строкой запустить код в главном потоке, потому опустил эту часть.
Так может сначала нужно разобраться в критикуемом?
Z>и это только одна конкретная мелочь, коих в свифте, конечно же, можно привести полно. когда проект большой, то таких мелочей вагон и ты начинаешь чувствовать их мощь и удобство. потому каждый раз говорить одно и то же реально задолбало.
Пока не видно никакой пользы, а создавать вручную диапазон HTTP Codes для проверки на Success и кичиться этим — это от большого ума (нет).
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Klikujiskaaan, Вы писали:
K>>Какие проекты сравнительно небольшие?
CC>https://unity3d.com/games-made-with-unity
Battletech и Escape from Tarkov — это небольшие проекты?
Z>var array = Enumerable.Range(200, 299).ToArray(); Z>if (foo == null || !array.Contains(foo.someValue)) {
достаточно экстеншена bool IsWithin(this int value, int minimum, int maximum), который проверит значение: statusCode.IsWithin(200, 299)
Z>я уже и не помню, как в сишарпе одной строкой запустить код в главном потоке, потому опустил эту часть.
ровно так же как и в другом языке поддерживающим лямбды – вызовом библиотечного метода, будь то GCD или другая либа.
P.S. не спорю – в свифте очень много удобных свистоперделок, которые упрощают жизнь
P.P.S. в котлине ещё больше, и есть смарт кастинг и корутины
Здравствуйте, std.denis, Вы писали:
SD>P.S. не спорю – в свифте очень много удобных свистоперделок, которые упрощают жизнь SD>P.P.S. в котлине ещё больше, и есть смарт кастинг и корутины
согласен про котлин. сам я с ним не работаю, так как с андроидом не имею дело. но когда изучал синтаксис, то периодически ловил себя на мысли "а ведь отличная же штука, хочу такое же в свифте". думаю, что это следствие того, что котлин моложе свифта и его разработчики потому смогли избавится от тяжелого наследия устаревших штуковин и сразу все сделать хорошо.
Z>думаю, что это следствие того, что котлин моложе свифта и его разработчики потому смогли избавится от тяжелого наследия устаревших штуковин и сразу все сделать хорошо.
котлин года на 2-3 старше свифта 😝
единственное что в нём откровенно раздражает, это отсутствие тернарного оператора (только if-else), и val а не let
Здравствуйте, std.denis, Вы писали:
SD>котлин года на 2-3 старше свифта 😝 SD>единственное что в нём откровенно раздражает, это отсутствие тернарного оператора (только if-else), и val а не let
Здравствуйте, zverjuga, Вы писали:
Z>джава и сишарп — это динозавры, который застыли во времени. громоздкие и с избыточным синтаксисом. сейчас появились более современные и удобные языки, с которыми работать гораздо комфортнее. и потому программисты будут переходить на них. если сишарп и джава не начнут шевелиться и эволюционировать, то ничего хорошего им не светит.
Эволюция ограничена первоначальными установками. Яркий пример — записи,
то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.
В то же время, есть надмножество сишарпа — немерл. который с легкостью реализует новые возможности благодаря системе макросов.
Не хочешь — не пользуешься, если же используешь библиотеку с записями, то просто видишь класс с параметризированным конструктором и ридонли пропертями,
сейчас правда в коре благодаря рослину возможно слабое подобие этого(см ).
— прикольно же(если рид-конфиг вернул nil то cfg по умолчанию)?
Джава конечно более стара, это проявляется в гораздо более медленном старте приложений (на и5-ом до 5-10 секунд!).
Все-таки коре пошустрей.
Хотя появился грааль вм которая вроде умеет в натив преобразовывать бесплатно. при это потребление памяти и скорость значительно улучшаются.
Фичи замусорили сишарп уже,
например деструктор. Реально, зачем он нужен?
есть Color c;
Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);
Язык от этого не становится лучше, он становится сложнее только.
Здравствуйте, Ватакуси, Вы писали:
В>Что случилось с такой перспективной технологией как .net?
С технологией самой по себе все замечательно. Под .net core серверные приложения можно делать кроссплатформенными.
Если нужен классический десктоп под винду — .net core вполне себе работает с WinForms и WPF.
Проблема, мне кажется, в двух вещах.
Отсутствие хайпа. Отпугивает всех, кто на него ориентирован — некоторых начинающих, часть людей с деньгами, определенный слой людей, которые принимают архитектурные решения.
Довольно большой порог входа. Язык C# большой, чтобы просто выучить все его фичи надо много времени. Чтобы научиться их применять надо практиковаться. А это не только время, но и качество практики. Так что большинство решает не заморачиваться а учить Го или Джаваскрипт.
Здравствуйте, Mamut, Вы писали:
M>Вообще, .net начинался 20 (!) лет тому назад, как строго windows-only технология в условиях, когда Винде не было и не предвиделось альтернатив.
Напомню вкратце историю возникновения C#. Вначале была Java. Главная идеология — программы должны работать на любой платформе, поэтому если кто хотел внести изменения в язык, должны были согласовывать с Sun. Microsoft и тогда считал себя круче других, и стал вносить изменения не согласовывая. Sun подал в суд на Microsoft и выиграл. После этого Microsoft отказался от Java и создал свой язык C#, который должен был вытеснить Java.
M>Мобильная и облачная революции произошли всего 10 лет тому назад и далеко не сразу. Падение популярности windows-only .net'а, как ни странно (сарказм), совпало с относительным падением популярности винды, как платформы.
Просто Microsoft решил захватить новые для себя ниши серверов и мобильников и выпустил Windows Server и Windows Mobile. Естественно под это дело начал проталкивать C#. Только не взлетело, и популярность C# пошла на убыль.
SD>>достаточно экстеншена bool IsWithin(this int value, int minimum, int maximum), который проверит значение: statusCode.IsWithin(200, 299) PM>Зачем все эти IsWithin, Contains, LINQ? Коды HTTP уже сгруппированы по сотням:
Да, про это уже говорилось тут, но это если рассматривать API библиотек, а zverjuga рассматривал средства самого языка, а не прикладных библиотек. Т.е. например проверку statusCode на диапазон 222..333
Здравствуйте, IID, Вы писали:
IID>Откуда взялся девелопер ?
А кто на жабе аппы обычно пишет?
IID>Изначальная мысль была что число огрызков стремительно сокращается, и их уже осталось совсем немного.
Дада, вот вот вымрут совсем.
IID>Собственно откуда взялись ценники-флагманы я тоже не понимаю.
Ты поди в плоском виде форум читаешь и веток обсуждения не видишь?
CC>>Ну и в целом платежеспособность/готовность покупать у людей с бюджетными моделями как правило ниже. IID>Неверно. Я уже писал про исследование рынка игр. Как раз небогатые люди с далеко не топовыми компами платили больше всего.
Эк ты сову растянул то!
Осталось ещё исследование погоды на Марсе приложить и тогда всё станет понятно каким боком игры на нетоповых компах к доходам разработчиков мобильных аппов.
IID>>>Речь о рыночной доле телефонов. И да — доля эпла только снижается. CC>>Пофигу. Интересует денежный выхлоп этой доли. IID>Меня не интересует.
IID>>>Причём тут доходы мобильных приложений? CC>>Это доходы разработчиков приложений.
IID>Откуда взялись разработчики мы так и не выяснили.
Ветку то перечитай наконец. Она началась с фразы "В последнее время выстрелили мобильные предложения. А там рулит Ява."
IID>А это я не тебе отвечал, ты тут в разговор вклинился.
По такой логике я Сократу отвечал а ты вклинился
IID> Впрочем у тебя свой мотив есть, вступиться за работодателя, шоп не обижали.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, IID, Вы писали:
IID>>Чтобы корова давала больше молока — её надо больше доить и меньше кормить
CC>Care to explain?
Z>то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Я тебе предметно показал, что все твои сдледующие утверждения по поводу C#/Java смешны, потому что они точно так же относятся к swift'у, который ты боготворишь. Или не относятся
— «это не та эволюция, которая от них ожидается. накидывание новых интерфейсов или расширений — это не эволюция, а расширение функционала».
Ты смотри, в Свифте накидывают все новые интерфейсы и расширения, причем постоянно
— «эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны, перекладывание части работы на компилятор и так далее».
В свифте синтаксис с каждой версией только усложняется
— «так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера. казалось бы, маст хэв, но делается через одно место.».
Ага. Вон в Свифте API просто загляденье, ага-ага. Всего-лишь в четыре раза длиннее, чем на C#, все делается в ручную, да еще на коллбэках построено, потому что в async/await Swift не умеет. Причем сам Lattnet говорит, что подобные API — говно и хочет, ой, расширить синтаксис и функционал чтобы получить async/await, акторов и т.п. Но это другое, ага, не то, что в C#
AA>Эволюция ограничена первоначальными установками. Яркий пример — записи, AA>то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.
Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое.
AA>Что касается жавы там тоже есть нюансы, см кложу. AA>- прикольно же(если рид-конфиг вернул nil то cfg по умолчанию)?
В какой-нибудь гипотетической библиотеке на Java с Optional'ами будет примерно так же:
read("config.json").orElse(...свой конфиг...)
Проблема в том, что в Java нет полезных шорткатов для создания map'ов, классов (как в C#) и т.п.
AA>есть Color c; AA>Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);
Не обязательно чище. Паттерн матчинг даже в урезанном виде — очень мощная штука, в которой главная мощь — это то, что ты можешь матчить и по значениям и по типам. Даже в твоем примере если матчить только по одному значению, то проще if. А если по нескольким? А если по нескольким условиям? А если по нескольким типам и условиям?
IID>Ты придуриваешься ? IID>Речь о платежеспособных юзерах. Которые ВНЕЗАПНО не коррелируют с ценой девайса. Откуда опять разработчики взялись ?
IID>>>>>Причём тут доходы мобильных приложений? CC>>>>Это доходы разработчиков приложений. IID>И эпла...
А ну да. Платежеспособные юзеры же платят только и исключительно производителю телефона за телефон. На этом их платежеспособность заканчивается. Как мы могли об этом забыть.
Здравствуйте, Mamut, Вы писали:
M>Ну то есть ты наезжаешь на Java, что там нет «красивого асинхронного API». Как говоришь, что в Свифте API говно, ВНЕЗАПНО выясняется, что надо всего лишь найти библиотеку?
M>Ну и у кого глупость?
я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
Здравствуйте, Mamut, Вы писали:
Z>>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
M>Потому что ты не осилил найти библиотеку, видать.
Зачем? Ты же будешь считать, что библиотека — говно, потому что там, например, не божественный `(200...299).contains` а богомерзкий `(200..300).Contains` или что-то в этом же роде.
будешь
Z>я хочу посмотреть, как в андроиде под джавой делаются удобные http(s) запросы на сервер. я как то упомянул, что в андроиде это по каким то причинам не реализовано
В Свифте тоже не реализовано. Но почему-то внезапно ты для Свифта нашел библиотеку. А для Java не осили найти. Но виновата Java
Z>, ты эту тему начал развивать. только запросы, никаких отдельных contains (правда ты пропустил Range(2000...300), против свифтового (200...300)) я сравнивать не буду, так как это тема для отдельных подветок.
Здравствуйте, Mamut, Вы писали:
M>guard в свифте существует ровно по одной причине: вместо того, чтобы «убрать синтаксические нагромождения, которые не нужны, и переложить части работы на компилятор» по твоим заветам, авторы свифта не осилили переложить на компилятор проверку на nil. То есть они не осилили ни полноценную проверку на nil (что можно делать if'ом), ни более-менее полноценный Optional (можно не такой, как в Haskell'е, но хотя бы как в Rust'е).
пример использования let и guar
исходный пример
func fooManualCheck(x: Int?) {
if x == nil || x <= 0 {
// Условия не соблюдены, выходим из функции
return
}
// Работаем с x
x!.description
}
этот же пример, но с использованием optional binding. недостаток — помещение x.description внутрь if
func fooBinding(x: Int?) {
if let x = x where x > 0 {
// Работаем с x
x.description
}
// Условия не соблюдены, выходим из функции
}
этот же пример, но с использованием guard. достоинство, что то, что после guard — это рабочий кот функции. то есть там кроме x.description может быть еще и простыня другого кода. то есть guard делает проверку на нуль и принудительное извлечение из оптиональной переменной, гарантируя, что x после него точно что то содержит
func fooGuard(x: Int?) {
guard let x = x where x > 0 else {
// Условия не соблюдены, выходим из функции
return
}
// Работаем с x
x.description
}
Я в курсе. Это — говно. Это ни if ни match (а ля rust) это какое-то говно посередине. Причем которое моментально становится максимально нечитаемым. Он почти полностью дублирует код if'а (то есть добавляет абсолютно лишнюю перегруженную конструкцию) и частично работает как match.
Причем это видно прямо в твоем же примере, но у тебя настолько глаз замылился своей верой в исключительность свифта, что ты этого не видишь:
func fooManualCheck(x: Int?) {
if x == nil || x <= 0 {
// Условия не соблюдены, выходим из функцииreturn
}
// Работаем с x
x!.description
}
// идентичен
func fooGuard(x: Int?) {
guard let x = x where x > 0 else {
// Условия не соблюдены, выходим из функцииreturn
}
// Работаем с x
x.description
}
разница только в том, что:
— у нас внезапно добавляется новый ненужный синтаксис (да еще и дико кривой: guard <condition> else {} вместо хотя бы guard <condition> {})
— guard магически распаковывает Optional
Они просто не осилили ни нормальный if (if не умеет делать проверку на nil) ни нормальный паттерн матчинг на Optional (как в Rust'е, да хотя бы как в C#). Мега-язык, ты что.
Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.
Здравствуйте, Mamut, Вы писали:
M>Они просто не осилили ни нормальный if (if не умеет делать проверку на nil)
ты в своем уме? никто тебе не мешает делать эту проверку
if x != nil {
x!.description // только тут придется использовать принудительное извлечение
или
x?.description // эти два примера в данном конкретном случае практически равносильны
}
guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль
guard let x = x
можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно
if let x = x {
x.description
}
M>Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.
ну это вообще капец. оказывается, что лучше использовать фильтр, чем просто lete
x.filter(x => x > 10).orElseThrow(...) // тут еще проверки на нуль не хватает
или
let x = x where x > 0 {
}
let и guard
1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок
2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется
проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение
Здравствуйте, Sinclair, Вы писали:
S>Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass.
здесь уже отвеченно тебе же http://rsdn.org/forum/flame.comp/7609323.1
S>Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так:
хорошо, с этим я согласен. за последними версиями сишарпа я не следил. видимо, сперли у свифта решение (сарказм если что).
M>А ну да. Платежеспособные юзеры же платят только и исключительно производителю телефона за телефон. На этом их платежеспособность заканчивается. Как мы могли об этом забыть.
я работаю в немецком телекоме и нам дают 1 телефон раз в 3 года бесплатно(на выбор 5 моделей), так вот, большинство выбирает huawei
„Nun gut, wer bist du denn?“ „Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.“
Здравствуйте, Mamut, Вы писали:
M>Что все равно приводит к выигрышу Шарпа, потому что ему не нудны никакие дополнительные синтаксические конструкции.
спорно, на мой взгляд. вариант на свифте читается слева-направо как есть. одно условие следует за другим, и если любое из них нарушено, срабатывает блок else.
вариант на сишарпе уже заставляет вникать в логику. времени на осмысление условия требуется больше. сначала нужно прочитать условие внутри скобок, потом его еще и инвертировать. и потом сообразить, в каком случае будет true или false
swift
guard let condition1, condition2 else { // условия выполняются слева направо
// не выполнено любое из условий
}
c#
if !(condition1 && condition2) {
// не выполнено любое из условий
}
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Mamut, Вы писали:
Z>если бы свифт был под виндой, я бы только на нем и сидел и забыл бы о сишарпе как страшный сон.
сразу видно человека, который на нём никогда ничего серьезного не писал (ну или человека который не писал на нём года 3 назад).
сам ушёл со свифта (и всей этой эппл-параши) года 3 назад на .net и ни разу не пожалел.
Здравствуйте, Bj777x, Вы писали:
B>я работаю в немецком телекоме
Поди в Telefonica Deutschland?
B>на выбор 5 моделей
И каких же?
B>так вот, большинство выбирает huawei
Огласите весь список пожалуйста.
Здравствуйте, Mamut, Вы писали:
AA>>Эволюция ограничена первоначальными установками. Яркий пример — записи, AA>>то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.
M>Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое.
nemerle:
[Record]
class Person {
public name : string;
public age : int;
public sex : bool;
}
//равносильноclass Person {
public name : string;
public age : int;
public sex : bool;
public this (name : string, age : int, sex : bool) {
this.name = name;
this.age = age;
this.sex = sex;
}
}
scala:
case class Book(isbn: String)
val frankenstein = Book("978-0486282114")
F# —
type Person = {
Id : int
Name : string
}
В последних двух еще сравнение по значению по умолчанию и иммутабельность, в немерле сравнение отдельно через атрибут-макрос StructuralEqual(как-то так)
в C# хотели такое ( с 7 версии):
class Point(int X, int Y, int Z);
AA>>есть Color c; AA>>Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);
M>Не обязательно чище. Паттерн матчинг даже в урезанном виде — очень мощная штука, в которой главная мощь — это то, что ты можешь матчить и по значениям и по типам. Даже в твоем примере если матчить только по одному значению, то проще if. А если по нескольким? А если по нескольким условиям? А если по нескольким типам и условиям?
Не спорю, просто похожий пример мусолится во многих публикациях о фичах сишарпа.
Здравствуйте, Mamut, Вы писали: M>А ну да. Платежеспособные юзеры же платят только и исключительно производителю телефона за телефон. На этом их платежеспособность заканчивается. Как мы могли об этом забыть.
Купил за кеш айфон — и ты больше не нищеброд, а респектабельный платежеспособный господин.
Приятно так думать, правда ?
Но нет.
Даже в России айфон может купить любая уборщица. Обычно чем беднее человек, тем дороже у него телефон.
Как сказала одна учительница в 90е, находясь на грани голодного обморока: "никто не видит что мы кушаем, зато все видят во что мы одеты". На модную одежду она тратила почти весь свой доход.
А теперь пруф:
Applicants with more advanced degrees tend to have higher incomes. Does that mean that those with high incomes are less likely to be video gamers as well? We looked into the percentage of applicants with gaming purchases by income group to find out.
The percentage of applicants with video game purchases by income group is fairly consistent across the board. Income doesn’t make a big difference in video gaming, though there is a small but notable decrease in video gaming in applicants who make more than $90,000 per year, where the share of video gamers begins to drop off from 12% to 9%.
Здравствуйте, Mamut, Вы писали:
M>>>Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое. AA>>nemerle:
M>C#:
M>
M>public class Person
M>{
M> public String name;
M> public int age;
M> public bool sex;
M>}
M>// ...
M>var person = new Person
M>{
M> name = "Mamut",
M> age = 0,
M> sex = true
M>};
M>
Здравствуйте, Mamut, Вы писали:
M>И тем не менее, «исчезающие айфоны» приносят больше половины денег, чем «90% андроида». Не Эпплу приносят, замечу.
Как же не эпплу, если 30% от продаж в iStore принудительно отчисляются ? И только монстры типа Netflix продавили 85/15, и то со второго года использования, не раньше Первый год те же 70/30. А недавно гугл послал Epic с их Fortnite, которым коммисия гугла не нравится.
Ты б хоть структуру доходов эппла посмотрел. Услуги (софт, музыка, игры, фильмы и т.д.) приносят 13% дохода с самой высокой маржой в 63%. Для сравнения у железа маржа 34%. А доля айфонов в прибыли 62% и каждый год падает.
IID>>А теперь пруф:
M>2019-й еше не закончился, поэтому данные про 2018-й
И что ? Я этим не спорю.
Напомню контекст:
1) изначально я говорил о числе устройств, доходы притащили вы
2) также я не спорил с тем, что в Эппле умеют доить более качественно
2) ты пытался доказать, что проиозводимая устройство прибыль коррелирует с ценой устройства (подтекстом — с обеспеченностью владельца). Это неверно, по обоим пунктам.
Здравствуйте, IID, Вы писали:
M>>И тем не менее, «исчезающие айфоны» приносят больше половины денег, чем «90% андроида». Не Эпплу приносят, замечу. IID>Как же не эпплу, если 30% от продаж в iStore принудительно отчисляются?
А 70% кому достаются?
IID>Напомню контекст:
S>В последнее время выстрелили мобильные предложения. А там рулит Ява.
CC>Не под iOS
IID>Этой iOS уже почти не осталось
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, IID, Вы писали:
M>>>И тем не менее, «исчезающие айфоны» приносят больше половины денег, чем «90% андроида». Не Эпплу приносят, замечу. IID>>Как же не эпплу, если 30% от продаж в iStore принудительно отчисляются? CC>А 70% кому достаются?
Так эплу приносят или не приносят ?
IID>>Напомню контекст: CC>
CC>>Не под iOS
IID>>Этой iOS уже почти не осталось
C0x>А с чего ты взял что у .net падение популярности?
Даже в первую десятку не входит по популярности запросов Гугл.
Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET. Это 3 банка из первый пятёрки и очень крупные мировые программерские конторы. Так же гос. учереждения (размером с министерство) в странах ЕС.
class TestClass {
constructor(name: string, private address: string, public city) { }
testMethod() {
console.log(this.name) // Compiler error: Property 'name' does not exist on type 'TestClass'.
console.log(this.address);
console.log(this.city);
}
}
const testClass = new TestClass('Jane Doe', '123 Main St.', 'Cityville');
testClass.testMethod();
console.log(testClass.name); // Compiler error: Property 'name' does not exist on type 'TestClass'.
console.log(testClass.address); // Compiler error: 'address' is private and only accessible within class 'TestClass'.
console.log(testClass.city);
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AA>>Зачем public?
S> А чтобы понимать, что это свойство. Оно может быть и не публичным
а если свойств будет сто штук, их нужно все будет в конструкторе перечислять? а если только часть из них нужно инициализировать? как по мне, все таки удобнее традиционный путь
class Foo {
public Property1
private Property2
...
public Property100
}
var foo = new Foo { Property1 = 1, Property100 = 100 } // инициализируешь только те свойства, которые считаешь нужным
Z>а если свойств будет сто штук, их нужно все будет в конструкторе перечислять? как по мне, все таки удобнее традиционный путь
Z>
Z>class Foo {
Z> public Property1
Z> private Property2
Z> ...
Z> Public Property100
Z>}
Z>var foo = new Foo { Property1 = 1, Property100 = 100 } // инициализируешь только те свойства, которые считаешь нужным
Z>
Нет конечно. Ты так же можешь их в классе прописать.
Просто здесь экономия на публикации свойств.
Кроме того конструктор выполняет не только установку свойств. https://metanit.com/web/typescript/3.1.php
и солнце б утром не вставало, когда бы не было меня
Z>опять так, сравниваем синтаксис создания списка по заданному диапазону в свифте Z>
Z>(200...299)
Z>
Z>против сишарпа
Z>
Z>Enumerable.Range(200, 299)
Z>
Вы чего с ума сошли проверять попадание в диапазон через Enumerable.
Тут помоему единственное нормальное решение — if ( code >= 200 && code <= 299 )
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Споришь.
IID>Напомню контекст: IID>1) изначально я говорил о числе устройств, доходы притащили вы
ПРитащили потому что число устройств, как оказывается, еще не самое главное.
IID>2) также я не спорил с тем, что в Эппле умеют доить более качественно
Ты на полном серьезе считаешь, что все 100% "worldwide gross revenue" от мобильных приложений идут Эпплу? И все 100% Worldwide Gross Mobile Revenue идут ему же?
IID>2) ты пытался доказать, что проиозводимая устройство прибыль коррелирует с ценой устройства (подтекстом — с обеспеченностью владельца). Это неверно, по обоим пунктам.
Здравствуйте, CreatorCray, Вы писали:
S>>>В последнее время выстрелили мобильные предложения. А там рулит Ява. TSP>>В геймдеве популярен Unity. А там C# CC>Для сравнительно небольших проектов. Потом упираются в ресурсы.
Это давно не так, на Unity делают triple-A игры.
Навскидку: Сities:Skylines c тысячами человечков-автомобилей, шарящихся на карте в реальном времени, никто никуда не упирается и очень приятно выглядит.
А это 2015 год.
На Юнити разве что шутеров не вспомню, да и то на PC, потому что в мобильном сегменте сейчас всех рвёт Call of Duty: Mobile.
Который, внезапно, тоже на Unity.
Здравствуйте, Max Mustermann, Вы писали: MM>Это давно не так, на Unity делают triple-A игры.
Ты похоже значение этого термина не понимаешь.
Triple A games (also known as AAA) are simple games (console or PC) that were developed under the highest development budget of that current time AND are highest promoted.
MM>шарящихся на карте в реальном времени, никто никуда не упирается
Обсчёт логики CPU-bound и не зависит от рендерера (Unity) MM>и очень приятно выглядит.
Мнээээ... Разишо издали.
Здравствуйте, Ватакуси, Вы писали:
В>Даже в первую десятку не входит по популярности запросов Гугл.
На основе запросов в гугл JS менее популярен, нежели C#.
В>Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET.
Здравствуйте, Ватакуси, Вы писали:
C0x>>А с чего ты взял что у .net падение популярности?
В>Даже в первую десятку не входит по популярности запросов Гугл. В>Весь крупняк (на основе моего опыта и моих знакомых, конечно), или перешёл или переходит с .NET. Это 3 банка из первый пятёрки и очень крупные мировые программерские конторы. Так же гос. учереждения (размером с министерство) в странах ЕС.
Не понимаю а в чем смысл то переходить? Куча библиотек, куча опенсорса. Приложения можно ваять на любую тему. В десктопе так вообще альтернативы нет. Сервера сейчас можно на .net Core ваять.видел вакансии на F#. Это конечно может и не си# но в тот же .net.
Здравствуйте, Mamut, Вы писали:
M>То есть чтобы было понятнее: Swift — единственный в мире язык со «парадигмой строгой типизации, который не допускает своевольничания и предположений», в котором переменная внутри scope'а меняет тип в зависимости от того, участвовала она внутри присваивания в определенной конструкцией или не участвовала.
Справедливости ради в шарпе есть похожая ситуация, когда async у метода меняет тип return с Task<T> на T.
Здравствуйте, Serginio1, Вы писали:
S>[cs] S>class TestClass { S> constructor(name: string, private address: string, public city) { } S>}
Может, конечно и удобно тому кто привык, но private намекает, что логика сложнее обычной DTO,
в этом случае явная реализация на мой взгляд лучше для понимания.
Здравствуйте, varenikAA, Вы писали:
AA>Здравствуйте, Serginio1, Вы писали:
S>>[cs] S>>class TestClass { S>> constructor(name: string, private address: string, public city) { } S>>}
AA>Может, конечно и удобно тому кто привык, но private намекает, что логика сложнее обычной DTO, AA>в этом случае явная реализация на мой взгляд лучше для понимания.
Ну это удобно для небольших классов, когда их создается куча достаточно удобна. По конструктору ты можешь понять все о классе
и солнце б утром не вставало, когда бы не было меня
У меня на рабочем ноуте самое жирное приложение сейчас — студия (1Гб оперативки). На втором месте, внимание — Teams, который отожрал полгига. По моему тут больше не о чем говорить.
Здравствуйте, CreatorCray, Вы писали:
MM>>шарящихся на карте в реальном времени, никто никуда не упирается CC>Обсчёт логики CPU-bound и не зависит от рендерера (Unity)
Обсчёт логики на C# и не упирается. Причём на Mono, который не эталон быстродействия. Речь про Unity ведь в контексте C#/дотнета.