#你們覺得什麼語言被高估了

1 messages · Page 1 of 1 (latest)

young gulch
#

英文

fast shard
#

文言文

violet laurel
#

TypeScript

hollow wigeon
fast shard
#

Python在很多方面確實貢獻很大ㄅ

#

缺點就 執行慢吃記憶體之類的 但也換來了新手友善和可讀性

#

只能說特色鮮明ㄅ

violet laurel
#

在應用方面 尤其是數據科學之類的
就很少人能跟它打

fast shard
#

還有網站後端 django和flask市占率也很高

#

brainfuck確實被高估了

fast shard
#

Python的物件導向我不知道 不過基礎語法確實比大多數其他語言簡潔ㄅ

violet laurel
#

lambda 超不簡潔
因為作者不喜歡 functional programming

fast shard
#

好ㄅ 我碰Python還很淺

violet laurel
#

Python 寫 lambda 要用 lambda x: ...

#

對比 Haskell 的 \x -> ...

#

而且 reduce filter 丟在 functools 裡面w

#

雖然可以解釋成說 寫 Python 可以不必要用到他們
但就是少了一個發展的可能

fast shard
#

JS data type不是很渾沌嗎

violet laurel
#

JS 更糟 我寧願用 Python

#

沒碰過 但我覺得應該會比 JS 好

#

JS 在 functional 的體驗我覺得更糟
在 Python 我如果用 f(obj.method)，f 裡面能夠呼叫 obj.method
但在 JS 就可能會因為 this 跑掉所以不能動之類的

cursive dock
#

我最討厭Python但問題是一堆腳本都只能Python寫suicide

fast shard
#

C++和C#還好ㄅ

#

不知道 至少我目前學到運算子多載還沒遇到真的很難的語法或特性happythonk

lucid knoll
#

代碼 支語警報觸發

#

「代碼」是中國用語ㄅ（

fast shard
#

程式碼

fast shard
fast shard
#

很多中國用語在台灣有另外一個意思 如果混用容易造成誤會 因此我自己會盡量使用在地化的詞彙

#

如果表達的清楚的話其實沒什麼問題 就像中英夾雜差不多概念吧

empty grove
#

你說像土豆之類的嗎

fast shard
#

喔土豆

warm herald
cursive dock
#

可讀性0

violet laurel
#

以我當程式語言助教這麼多次的經驗
如果是新手的 code，那 Python 滿可讀的

#

強制要用縮排來表示區塊這一點就贏了#

fast shard
violet laurel
#

那種花括號語言、end 語言
讀二十幾份沒有縮排的 code 真的很痛苦 O<<

keen summit
warm herald
keen summit
#

而且別忘了python之禪

#

優美優於醜陋，

明瞭優於隱晦；

簡單優於複雜，

複雜優於繁雜，

扁平優於嵌套，

稀疏優於稠密，

可讀性很重要！

特例亦不可違背原則，

即使實用比純粹更優。

錯誤絕不能悄悄忽略，

除非它明確需要如此。

面對不確定性，

拒絕妄加猜測。

任何問題應有一種，

且最好只有一種，

顯而易見的解決方法。

儘管這方法一開始並非如此直觀，

除非你是荷蘭人。

做優於不做，

然而不假思索還不如不做。

很難解釋的，必然是壞方法。

很好解釋的，可能是好方法。

命名空間是個絕妙的主意，

我們應好好利用它。

fast shard
#

命名空間真的是絕妙的主意嗎

#

還是這是反串

keen summit
#

./run ```py
import this

hearty nimbusBOT
#

Here is your py(3.10.0) output @keen summit

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
violet laurel
fast shard
keen summit
fast shard
#

但說真的我也沒用到std以外的東西

warm herald
fast shard
spark bay
#

別的語言的lamda珍香

violet laurel
#

比如 Haskell 的 \x -> x+1

keen summit
#

\x -> x+1
lambda x: x+1

violet laurel
#

\m n f x -> m f (n f x)
lambda m: lambda n: lambda f: lambda x: m(f)(n(f)(x))

warm herald
#

py的lambda超令人崩潰

violet laurel
#

他就是不想讓你玩 lambda 的意思

warm herald
#

他沒想過sort之類的就會用到了嗎

violet laurel
warm herald
violet laurel
#

Python 沒有這種用法 ODO

keen summit
#

簡單來講 就是傳入自訂function會用到

keen summit
violet laurel
#

Python 傳入的叫做 key function，不是讓你比較的

keen summit
#

dict(sorted(dict.items(), key=lambda x: x[1]))

violet laurel
#

那個跟上面的例子不同

keen summit
#

hmm

#

不過我最近常用到的是生成dict

# 
base = lambda color: {
  "name": f"{color}_block"
}
```這類的
violet laurel
keen summit
#

那我改一下

# 
>>> def dec(f):
...     def wra(*arg):
...             print('a')
...             return f(*arg)
...     return wra
... 
>>> @dec
... def foo(): pass
... 
>>> foo()
a
>>> @lambda f: lambda *arg: [print('a'), f(*arg)][1]
... def foo(): pass
... 
>>> foo()
a
```當然還有這種邪教寫法
violet laurel
#

這還蠻 functional 的(

keen summit
#

這其實差不多

#

單純是把func有沒有提出來的問題