混这个版有些年头了，老实说最离不开的居然是Python。不是因为它多漂亮，是它那个REPL把"猜想—验证"的循环压得太短。
早些年用别的语言，总得先把整段逻辑想周全，编译、跑、看结果、再回头改，中间那道摩擦特别消磨人。后来习惯在Python里敲一行回一行，试探一个数据结构、查一个边界条件，像跟机器实时聊天。debug也不再是"改—编译—跑"的三拍子，而是边问边答。
生态也实在省心。从抓网页到跑个小模型，pip一下基本都有轮子。想法落到原型常常就几行，注意力全留给问题本身，不必先跟语法细节搏斗。
其实
当然也有人嫌它慢、嫌它太松散。可对习惯性先把念头试出来再谈工程的人，它刚好卡在最舒服的那道缝里。
你那句"像跟机器实时聊天"，我盯着看了两遍。早些年我折腾代码，改一行等编译的空当够下楼买包烟。后来习惯了敲一行回一行的节奏，才发现思路能跟手指贴得这么近，回不去了。
我觉得吧
不过有一回一个朋友跟我聊，说这即时反馈有时候也是温柔的坑——人一舒服就懒得先在脑子里把逻辑走通，总想着"先试试"，试着试着架构就歪了，原型飞快，真要落地又得推倒重来。我觉得他说得在理，但这也就是个习惯问题，不碍着python本身好用。
坦白讲凌晨守着屏幕配杯espresso，也算这年头少有的奢侈了。
我当年也是被"敲一行回一行"的手感黏住的，不过有个细节想补：REPL并非Python独创，Lisp、Smalltalk那批动态语言早就是边写边验的路子。Python让人觉得"边问边答"特别顺，一大半功劳其实在IPython/Jupyter把交互体验补得太完整（原生那个REPL连像样的tab补全都没，跟"实时聊天"还差得远）。
"不必跟语法搏斗"在原型期确实成立，动态类型是红利。但脚本过千行后，没了静态检查兜底，改一个函数签名时那种心虚，比编译型语言重不少。我前阵子回头收拾早年随手写的爬虫就是这感觉，跑着没毛病，总觉得哪块要塌。
慢和松散那两点吐槽，倒恰恰是它的代价。对你这种习惯先试出来的人，这点代价换手感，值。
关于REPL把反馈环压短，我想补一个容易忽略的前提：这种交互范式远在Python之前就存在。Lisp从六十年代起就靠eval做实时求值，Smalltalk、APL更早把"人机对话式编程"当成常态。其实Python真正做到的，是把这套体验从学术圈拉到大众面前，语法平、标准库全，让用惯C/Java的人第一次摸到边敲边验的手感。
所以你写"早些年用别的语言总得想周全再编译"，在编译型语言范围内成立，但交互式语言一直都在，只是没出圈。eigentlich Python胜在可达性，不是发明了短循环。你那个"其实"后面想接的，莫非就是这个意思？
你聊的这个"把念头试出来再谈工程"，我年轻的时候其实走的是反路。那会儿总觉得正经人得先在纸上把流程图画明白，再动手，不然就是瞎搞。后来泡在论坛里看人聊这些，才慢慢改过来——不是改成随便乱试，是发现边敲边看其实逼着你想得更清楚，因为机器不糊弄你，你猜错了当场就给你脸色看。
不过说点补充的。那个短反馈环确实是好东西，可它有个不太显眼的副作用。人在 REPL 里待顺手了，容易把"能跑"当成"懂了"。我见过不止一回，一段脚本交互着试出来了，问他为什么这么写、边界上会出什么岔子，答不上来。说白了，即时反馈把"验证"变得太便宜，反而把"想透"这一步偷懒跳过去了。
所以我现在更偏向一种折中：念头先用 REPL 探，探明白之后，关掉它，在脑子里或者纸上把这趟路重新走一遍，确认自己真懂了，再落到正式代码里。REPL 是探路的手电筒，不是盖房子的地基。坦白讲
话说回来
你前面说"嫌它松散"那些人，我觉得他们骂的其实不是 Python，是怕自己陷在那种随手试、永远不收口的状态里。你"先试后工程"这句话，已经把分寸说出来了，只是这分寸得靠自己拿，工具帮不了你。说实话
你们现在写 Python 都直接用原生 REPL，还是上了 IPython、notebook 那一套？我前阵子看人演示 notebook，感觉那东西把"边问边答"又推远了一步，倒有点像写带注释的实验报告了。
关于"猜想—验证"那段我挺有共鸣，但想补一点可能没说全的地方。
把功劳全归给 Python 原生的 REPL，其实有点低估了后来的变化。真正把那条循环压到极致的，是 IPython 和 Jupyter——tab 补全、内联画图、报错跟上下文并排摆出来，这些才是让"边问边答"顺手的关键。裸 REPL 敲一行回一行，跟早年 Scheme 的交互式环境比，体验并没有本质飞跃。
再说"松散"那条批评。它其实不是品味问题，而是成本转移：松散让原型快，可一旦原型长成系统，没有静态检查兜底，重构和接手别人代码的心智负担会成倍回来。2014 年 PEP 484 引入类型标注、mypy 慢慢成熟，某种程度上就是社区在补这道缝——既想留住短循环，又把后期的安全感拿回来。
还有，"短循环"现在不算 Python 独占。cargo watch 配 Rust、Go 的即时编译、Julia 的 Revise 工作流，都在往同一个方向挤。Python 占的先机更多是生态和习惯，不是机制上的唯一。
你那个"卡在最舒服的缝里"我完全认同，只是这条缝会随项目从玩具长成工程而慢慢移位，等到那时候，舒服的位置大概得靠类型标注和测试重新去找了。
交互式这桩事Lisp、Ruby的irb早就有，不算Python独门。它真正占便宜的，还是你说的生态那条。
我基本也是 有点啥念头先开repl敲两行 比憋一大段再跑舒服多了
我年轻那会儿可没这福气。头回碰计算机，写点东西得先在纸上把道道理清楚，因为跑一趟太费劲…，错了就得推倒重来。那时候总觉得，人跟机器中间隔着一层，得先把自己顺成它能认的样子，才轮得到试。
怎么说呢
你帖子里那句“边问边答”戳到点上了。后来我也跟着在解释器里一行行敲着玩，哪怕不是干正经活，随手算笔账、理个数，也懒得开计算器了。前阵子帮家里理一笔零碎账，要搁以前早按计算器按到头疼，那回直接敲两行就完事。这种“念头一冒头马上能验”的爽利，别的语言确实给不来。这事吧
不过我想补半句。这短循环太顺手了，有时会让人赖在这层不肯往上走。想当年我瞧过不少人，原型写得飞快，真要让它天天跑、要让旁人接手、要隔半年自己还看得懂，就犯难。那种松散省的是“当下写”的力气，欠的往往是“往后养”的账。
所以 Python 卡的那道缝我赞成，只是往里是原型，往外还得自己搭梯子。用顺了它，最好也留手收束的功夫，别让顺手成了将就。
你这贴"其实"后面好像断在半道了。慢那桩事我倒觉得没那么要紧，重活丢给numpy、pandas那些底层轮子，上手写的还是Python，跑起来并不慢。
我年轻那会儿可没这好事。最早摸计算机的时候，写个东西得先把逻辑在纸上捋顺，录进终端，然后等机器跑，错了再从头来。说实话楼主说的那道摩擦，我太懂了，特别消磨人。
后来头一回碰到能一行行敲、一行行看结果的环境，那种感觉……像是终于不用隔着一堵墙跟机器说话了。你说的"边问边答"，确实就这么回事。
不过有件事我想多嘴一句，不是泼冷水哈。这节奏太舒服，有时候人会陷进去，一直试探局部、调那个边界条件，结果本该先想清楚的整体结构，被拖到最后才去碰。我见过几个年轻人，原型飞快，真要收拢成能用的东西反而卡住，因为骨架一直没立起来。慢慢来
所以我现在的习惯是，试探归试探，但每天收工前逼自己把当天那些零碎验证，归拢成一段能讲清思路的东西。REPL是拐杖也是陷阱，用得顺的时候，反而更得留神别让它替你思考。
你现在还停在默认REPL，还是早上了IPython、notebook那类？我觉得吧我前两年才被朋友拉着试notebook，倒有点相见恨晚。
松散这点值得商榷。3.10加的结构化模式匹配、加上typing生态，这几年明显在往严谨走。