MoreRSS

site iconPan93修改

目前是 Zeabur 的 Backend intern,也是一個大學生。
请复制 RSS 到你的阅读器,或快速订阅到 :

Inoreader Feedly Follow Feedbin Local Reader

Pan93的 telegram 的 RSS 预览

🖼

2025-01-17 21:48:49

小紅書 和 TikTok 都被中華電信的 DNS 解析到 127.0.0.1 了,簡單來說就是被遮掉了。使用 Cloudflare DNS (1.1.1.1) 或 Google DNS (8.8.8.8) 的應該不受影響。 ...

2025-01-17 21:48:12

小紅書 和 TikTok 都被中華電信的 DNS 解析到 127.0.0.1 了,簡單來說就是被遮掉了。使用 Cloudflare DNS (1.1.1.1) 或 Google DNS (8.8.8.8) 的應該不受影響。

感謝 Chris 和 Lester 的發現!

以後用 ECMAScript 稱 J***Script 吧

2025-01-15 14:48:05

以後用 ECMAScript 稱 J***Script 吧

🔁 甲骨文拒绝放弃“JavaScript”商标 甲骨文因拒绝放弃“JavaScript”商标所有权而面临Deno Land的法律挑战。该商标是甲骨文2009年收购Sun Microsystems时继...

2025-01-15 14:47:52

Forwarded From 科技圈🎗在花频道📮

甲骨文拒绝放弃“JavaScript”商标

甲骨文因拒绝放弃“JavaScript”商标所有权而面临Deno Land的法律挑战。该商标是甲骨文2009年收购Sun Microsystems时继承而来,但Deno Land认为“JavaScript”已成为通用术语,且甲骨文未积极使用或控制该名称。JavaScript创始人Brendan Eich及开发者社区广泛支持Deno Land的行动,认为此举将影响JavaScript品牌的未来及其在科技行业的开放使用。

Deno Land于2024年11月向美国专利商标局提交请愿书,要求取消甲骨文的商标。甲骨文需在2025年2月3日前作出回应,否则案件可能进入默认判决阶段。若甲骨文坚持不放弃,争议将进入法庭审理。开发者社区已发起公开信,获得超10,000个签名,呼吁甲骨文放弃商标控制权,以确保JavaScript名称的开放使用。

Deno

📮投稿 ☘️频道 🌸聊天

🔁 React Native 是不是可以被 Jetpack Compose 和 Swift UI 替换掉了,这两个都是声明式 UI。现在让 AI 翻译成对应的原生平台,感觉也不是不行。当然这个想法...

2025-01-14 18:44:28

Forwarded From 厘米碎碎念

React Native 是不是可以被 Jetpack Compose 和 Swift UI 替换掉了,这两个都是声明式 UI。现在让 AI 翻译成对应的原生平台,感觉也不是不行。当然这个想法是很理想的,里面会有无数个原生平台的坑。主要是 RN 很多坑直到现在依旧填不完,其实也填不完……远程平台本身就一堆问题,比如苹果有一些疑难杂症得用 OC 来写。苹果开发很多时候就是吃这些经验的,RN 很难有那些精力填平。

↩️🔁 首先「AI 翻译成对应的原生平台」這點基本上非常難搞,雖然現代 LLM 都稱自己有著 128K 的 context length,但實踐上超過一定的字數後,後面的內容會開...

2025-01-14 18:44:28

Forwarded From 平底鍋

Pan 的神奇個人頻道:

React Native 是不是可以被 Jetpack Compose 和 Swift UI 替换掉了,这两个都是声明式 UI。现在让 AI 翻译成对应的原生平台,感觉也不是不行。当然这个想法是很理想的,里面会有无数个原生平台的坑。主要是 RN 很多坑直到现在依旧填不完,其实也填不完……远程平台本身就一堆问题,比如苹果有一些疑难杂症得用 OC 来写。苹果开发很多时候就是吃这些经验的,RN 很难有那些精力填平。

首先「AI 翻译成对应的原生平台」這點基本上非常難搞,雖然現代 LLM 都稱自己有著 128K 的 context length,但實踐上超過一定的字數後,後面的內容會開始進入臆想的狀態。基本上你不能輸入整包程式碼甚至是整段 code 進去,你一定要自己花時間分解任務,然後寫個 Agent 來達成你的目標。

如果你不能輸入整段 code,通常只能靠 總結 或者是 只傳入一部分的 code 來逐步翻譯。通常你預期 code 是 1:1 的(行為到介面都應該一致),但一方面 Android 跟 iOS 很多邏輯不是 1:1 的,另一方面是 LLM 產不太出穩定的結果,比如說同一段 function 送進 LLM,產出的 function signature 不能相同。signature 不同就足以造成大問題,更不用講 LLM 可能會在邏輯上的細微差異出差錯了。你或許會想「我把新改好的 code 傳進去就好啦!」但是 LLM(至少在沒有進行太多 engineering 的情況下)還是挺容易搞砸你原本寫的 code 的,你希望他多加 X 功能,但他會搞砸 Y 功能然後忘記自己要實作 X 功能。LLM 也不見得可以理解你的 design system,所以你也可能會花很大的精力在調整樣式。

最後,你要修正這些問題,假如你不懂這些知識,肯定還是得找 Android / iOS 的工程師來修。搞到最後,你還是回歸到請 Android + iOS engineer 的時代,AI 到頭來只是在製造低價值的 code 來搞出麻煩。React Native 或 Flutter 至少對於很多需求是夠用的,他的 Bridge 也至少是穩定、可以復現的 🙂