本文来源：时代财经 作者：王婷
图源：pexels
“发明摇一摇广告的人真是天才，天天一碰手机就跳转到（购物软件的）双十一专场。”在今年双11大促期间，摇一摇跳转广告泛滥，引发诸多用户吐槽。
互联网大厂内部人士常乐年告诉时代财经，11月以来，苹果公司已通知国内多家头部App要求它们移除陀螺仪权限，摇一摇跳转广告被禁止。
据他所知，这些收到通知的App包括但不限于在线视频软件、短视频软件、音频软件、邮箱软件等等，常乐年所在公司的App也不例外。
常乐年透露，接下来公司可能会发布新版本App，在苹果的App Store上架，新版本将没有摇一摇跳转广告，具体发布时间还不确定。
此消息得到一位广告从业者的印证。该人士表示，自己的客户也接到了苹果公司的通知，该客户是互联网大厂，旗下也有行业头部App。他对时代财经谈到，收到通知的不仅仅是头部App，波及范围要更广。
时代财经了解到，“摇一摇”功能调用的是陀螺仪权限，此功能由来已久，一度被很多App作为运营推广手段，可以用来抢电视红包、识别歌曲等等，如今不少被用于广告跳转，但有些手机没有陀螺仪权限开关，用户无法自行关闭。
“这种跳转属于App开发出来的商业模式，手机（厂商）很难去做系统性地调整。”手机大厂的一名工作人员对时代财经表示。
时代财经了解到，电商平台向各类App大量投放跳转广告，可通过不同方式触发，包括点击广告页面、晃动手机等，一旦触发，手机页面就会跳转到购物软件。
常乐年谈到，摇一摇跳转广告没了，不代表广告没了，只是少了一种跳转交互方式。他表示，这不影响公司履行与电商平台的广告合约，不涉及合同违约，“最近双十一，（电商平台）花了很多钱买广告。”
钉科技创始人丁少将则对时代财经表示，在移动互联网时代，模式创新是很重要的创新方向，摇一摇广告属于模式创新的一种，但无论怎么创新，都要给用户知情权、选择权。摇一摇跳转广告影响用户体验，取缔或者移除有利于广告市场、电商市场的可持续发展。
此前，中国信息通信研究院联合华为、小米、OPPO、阿里巴巴等企业制定了团体标准T/TAF 078.7—2022，于2022年11月由电信终端产业协会发布实施，该标准进一步细化了APP信息窗口通过“摇一摇”等方式触发页面或跳转至第三方应用的相关参数，提出“摇一摇”动作的设备加速度应不小于15m/s2，转动角度不小于35°，操作时间不少于3s等系列参考数值。
对此，安徽中皖律师事务所律师余颉告诉时代财经，从法律性质上来看，该规范属于《中华人民共和国标准化法》规定中的团体标准。团体标准是推荐性标准的一种，是市场自主制定的标准，属于自愿采用，没有强制性，但是团体标准应当符合法律法规和强制性标准的要求，符合国家有关产业政策。
（文中常乐年为化名）
在这一点上，我觉得我们在循环往复。每个概念都会在几年内重复出现，只是实施方式和名称略有不同而已
作为一名拥有 40 多年经验的开发人员，我可以告诉你这是事实，而且已经持续了很长时间。
一直都是
🌍 🧑🚀 🔫 🧑🚀
……并将永远是 *astronautmeme*
我也有同样的经历（🖐️hello），而且完全同意。
一针见血。
我想说的是，就像古埃及人拥有钻探石油的所有工程技术，却从未发现或尝试过石油一样。或者说，特斯拉创造了无线电所需的部件（他试图传输能量），尽管他从未在空中发射或接收过任何音频信号，但却在死后获得了荣誉。
我的意思是，很多东西在泛型/模板、垃圾收集等之前就已经存在了。
现在，我们将这些东西集合到一种语言中，它们与以前相比有了很大的不同，也变得更好了。
是的，老实说–对于一个正在考虑最热门趋势的新手来说，看看像 Ada 这样的古老语言，你就会感到震惊了。:D 它于 1980 年首次发布。https://ada-lang.io/
泛型、契约设计、生命周期检查、并发类型、约束、语义类型……
你所说的 ADA 并不是 1980 年的 ADA。例如，泛型出现于 2005 年，是基于 C++ 模板的。
编辑：澄清一下。Ada的泛型出现在2007年发布的Ada 2005版本中。.NET在2005年底发布的.NET Framework 2.0中采用了泛型。
2007 年发布的 Ada 2005 版本。
Ada83 已经有了泛型，而 C++ 的 STL 就是在用 Ada 编写的早期原型基础上诞生的。
我在 20 世纪 90 年代使用的是带有泛型的 Ada
这些年发生了很多变化，尤其是在 C# 网络生态系统中。
WebForms => MVC => Core => Blazor 等等。
它们是不同的，而不仅仅是重复同样的东西。但在它们进入.NET之前，它们确实存在于其他地方。
你怎么能忘记 silverlight 呢？
我一直在努力忘记 Silverlight，但烧伤的疤痕依然存在:)
我们还在用 ie 维持一台机器的运行，只是为了运行一个授权的 Silverlight 应用程序…
创伤后应激障碍
创伤后 Silverlight 开发
没错。我们（这个行业）不断发明新方法来做上一代人已经知道如何做的事情。
如果我们有某种学徒–>技工–>工匠大师的职业发展路径，那么应用程序的开发将受益匪浅。
在 “全部在服务器上！”和 “全部在客户端上！”之间嘀嗒嘀嗒地走来走去，如果我不觉得自己像个老顽固，而我又笑着第十二次看到它的话，这一点几乎是可笑的….。
10 打印 “YUP
20 GOTO 10
不要错过
我刚看到一篇文章，说 blazor 服务器端渲染是下一个伟大的东西，等等等等……所以我们要回到服务器渲染代码……使用 razor……就像 mvc 所做的那样？15 年前…
是的，用不同的名字，就像 angular 也在做的那样……或者朝那个方向发展
我认为 Blazor SSR 最大的亮点在于组件思维和组件构建。所有东西都是组件，包括页面。
这并不新鲜，网络表格就有 .ascx 又名用户控件。经典的 Asp 有 “包含”，即 ActiveX 控件
这也不新鲜
几乎所有适合 Blazor SSR 的东西都不应该脱离 SSR。
FTW！这是 WebForms 开发的巅峰之作
你让我想起了过去，我还记得那玩意儿问世时的激动心情
Blazor 是有状态的服务器端渲染，它取代了旧式的、缓慢的 MVC 无状态服务器端渲染，后者取代了旧式的、缓慢的有状态服务器端渲染，称为 asp webforms。
这篇文章是关于 blazor webassembly 的初始 SSR 吗？
我还没来得及全部看一遍，只看了标题和摘要
一切都是一个循环。想一想：最初，所有的东西都是在单一主机上运行的。后来，我们发现这样做成本太高，而且一切都需要横向扩展，于是我们放弃了大型机。后来，我们又觉得管理所有这些机器太难了，于是我们又开始使用大型集中式服务器，尽管是运行多个虚拟机，同时使用 Citrix 等桌面。现在，我们正在用容器取代虚拟机，用……取代桌面。我不确定什么会取代思杰。尽管自动化程度更高，但我们正在慢慢回归分散化的趋势。
是的，我们正在这样做。
还记得 “Xml 是未来 “吗？
https://www.bitecode.dev/p/hype-cycles
我认为这是因为 1.我们从未足够重视问题。只关注解决方案。2.上次搬家时，想要的人不在那里。
例如，react 的出现是为了解决一个非常具体的问题–知道要更新什么的痛苦。因此，它被设计成不更新，而是重新生成。
跳上 svelte 列车的人并没有体验到这种痛苦。相反，他们看到了反应是如何需要你明确知道更新的原因的，并发现这很痛苦。于是，他们制作了一个编译器来解决这个问题。
然后他们发现，要做到这一点并不总是那么容易。因此，他们引入了信号，以明确哪些因素会导致变化。
因此，这与其说是一个圆，不如说是一个来回摆动的钟摆。我只是想知道它是如何在中间的某个地方停顿下来的，但只要有新人加入，有旧人退出，我想每一代人都会重新发现过去的痛苦。
快到 30 了。让我感到惊讶的是，便携式存储的战争已经平息。旋转软盘、固态存储、大型/小型、密度不断增加。我以为战争会升级，直到每个人的钥匙链上都有 5 TB。但我没想到，人们会在需要的时候，在 3 分钟内下载 100 GB 的文件。然后将其丢弃，以后需要时再下载。如果是企业需要，你可以计算一下，按需下载比存储更便宜。
是啊，我们又回到了数据集中的时代，就像在大型机和哑终端时代一样。我在想，这是否就是为什么消费级存储的价格没有像 10-15 年前那样下降的原因。固态存储是最近唯一价格下降的产品。
让我感到惊讶的是，便携式存储的战争已经平息。
我想说，这也是一个不断来回摆动的钟摆。在早期的 Unix 时代，你会有一个连接到分时系统的哑巴 “终端”。后来，家用电脑开始流行。然后，Sun 试图建立 “网络计算”。然后，个人电脑变得越来越强大。现在，我们称之为 “云”。但智能手机也变得更加强大。
一些公司可以从租赁计算资源和存储容量的订阅服务中获益，而另一些公司则可以从人们直接购买本地资源和容量中获益。
LINQ 和泛型使 C# 领先于许多语言，而其他语言仍在追赶。
LINQ 在其他语言中的缺失真的伤害了我学习它们的意志。
每次使用其他语言时，我都会立刻感受到没有 LINQ 的沉重。作为一个 Rust 爱好者，我觉得它是功能最齐全的，但又不完全是。PHP 得到了 Laravel Collections 库，感觉与 LINQ 很接近，但还不够。围棋……也许有一天会有，但我不会屏住呼吸。
如果我们能得到总和类型、标记联合和错误值类型，我想我就没有理由再使用其他语言了。
其他语言是如何解决与泛型相关的问题的？ 都是工厂方法吗？
是的。在 1.16/17 版本之前，围棋就是这样的，那还是去年的事。地鼠对代码的编写方式（简洁性等）很有主见，对增加泛型的反应也是褒贬不一。在此之前，你必须为每种类型编写自己的列表代码。我并不精通此道，但我对从一开始就没有使用泛型感到惊讶，而且普遍认为泛型在地鼠圈中并不受欢迎。
保持代码简单，以便软件可靠性工程师能快速排除故障，是 go 的最初目标。源于 C++ 的泛型（又称模板参数）可能给最初的设计者留下了伤痕。试图理解一套你从未见过的 C++ 泛型模板可能需要一些时间……从 SRE 的角度来看，这是非常糟糕的。
花了整整一个工作日用 scala 映射 kafka 流……用了一大堆抽象和工厂…我很庆幸自己主要在 go 中工作……scala 代码几乎转换成了 main.go 文件中的 for 循环。
有相当多的语言拥有比 C#”更好 “或 “更强大/更灵活 “的泛型，但它们通常并不附带语言的某些控制功能，也无法与 dotnet 运行时相提并论。
在其他语言中也存在类似于 linq 的东西，只是很难对这些实现进行比较，因为你最终也会被归入其他功能的比较中。
LINQ 在 C# 中如此出色是因为 LIN 部分（语言集成查询）。
Java 的流就像没有语言集成的 LINQ，因此笨重得要命。
就 Java 而言，以我过时的经验来看，它与 C# 并无太大区别。可能有一些细微的差别我不记得了，但如果我没记错的话，共同点比不共同点多。
Java 其实没有泛型，只是编译器的一个小技巧。如果你问 Java 中的集合是什么类型，它每次都会说是集合。
这意味着你无法使用很酷的技巧，比如创建一个 T AddNew() 方法，因为在 JVM 看来，T 始终是对象。
有道理。我大概有十年没碰它了（希望以后也不会再碰），但我记得它的边缘有一些毛刺。谢谢你的解释。
我听说甲骨文公司想解决这个问题，但我不知道这是否还在他们的路线图上。
他们可能还没想好如何对该功能进行掠夺性定价。
是的，Project Valhalla（瓦尔哈拉计划）已经存在了 8 年左右，但我不知道何时或是否会将其添加到 Java 中。Loom 项目最后确实有了结果，所以 Valhalla 项目也许也会有结果。
甲骨文不再明确维护 java。
这就是所谓的 “类型擦除”（type erasure），.net 1.0 团队为了在最后期限前完成发布，不得不明确决定不这么做。从根本上说，他们决定将泛型的发布时间推迟到 3.0（？），以便能够完全支持泛型，而不是像 Java 那样采用擦除黑客技术。MSIL 的定义本质上就支持泛型，.net 中的数组也一直支持泛型。有点意思。
从根本上说，他们决定把泛型的发布时间推迟到 3.0 版（？
2.0.
微软研究院及时推动了正确的方法，这也算是一种运气吧。
Java 有泛型。JVM 有诀窍。
没错。但 Java 支持泛型中的通配符，而 C# 不支持。https://docs.oracle.com/javase/tutorial/extra/generics/wildcards.html
我发现从 Linq 来的 Java 流在使用上很不方便。一旦一个流被终止（例如通过 ToList()），你就不能再使用它，必须从源头重新创建它。与 Linq 这种顺畅的生产力三文鱼相比，感觉就像一个笨拙的附加组件，在上游欢快地游来游去。
它们可能有点笨拙，但并不是一种新的语言特性。所有的 java 流都只是 java 语言中的代码，并没有为它们添加新的语法。因此，它们是在与 Linq 不同的条件下产生的。它们的功能没有那么强大，但也不需要在语言层面上做任何改动。
在 Java 中，泛型被编译掉了，所有列表等在运行时实际上都是 list<object>
这似乎不是个好主意 😀 尤其是对堆栈类型而言
在我看来，类型擦除是 Java 泛型的原罪。他们选择了 JVM 的向后兼容性，却牺牲了开发人员的可用性和类型的固有安全性（不得不使用辅助方法和转换）。我真的认为 MSFT 的决定是正确的：有了类型擦除，像 LINQ 这样的东西就变得难上加难了。
不会吧？我一定是忘得太多了，或者我一开始就不知道这些东西。
从 C# 来的 Java 泛型太让人头疼了，因为运行时会丢失类型。
真的吗？
尤其是包含在 Linq 中的 Expression<T> 部分。Linq中包含的Expression<T>部分，它在很多库和BCL中都有使用，因为它允许你基本上保存一个AST，这样库就可以对它进行解析和处理（例如，EF将其转换为SQL，测试库进行强类型反射等……）。
还有运行时编译，表达式非常棒！
不过，函数式语言和 Lisps 早在 80 年代就有了懒序列。
LINQ 主要基于 Smalltalk 和 Common Lisp 集合，受到后来 Haskell 工作的影响，参见 Erik Meyers 在 .NET 上的工作。
https://github.com/ahmetb/go-linq 已经有 3 年没有动过了，但在使用泛型之前有过一次不错的尝试，但现在我们有了泛型，所以谁知道呢？
对我来说，.Net 领先的地方不是语言特性或性能。.Net在这些方面一点也不差，而且仍然相当出色。
但在开发人员体验方面，与其他主流语言相比，.Net 在调试、配置和部署方面要容易得多，这在我看来是极其片面的。有些语言在这方面也做得很好，但这个生态系统在很多方面都让它变得轻而易举，我再也不能在使用其他平台时不时面无表情了。
最近我最喜欢遇到的情况是 ThePrimeagen（我很喜欢他）和另一位开发者在流媒体上讨论技术问题。现在他们都讨厌微软和与之相关的一切。这两个家伙津津乐道于 Rust（我也很喜欢 Rust）的后端框架如何 “自动 “将 JSON 转换为类型化对象…..。我喜欢