-
1 # 量子糾纏速度之謎
-
2 # 老邢說吧
程式設計的難點不是程式語言,程式設計是一項多學科,多業務知識,涉及到演算法,美工,計算機系統軟硬體,網路系統軟硬體知識和技術等多方面知識和技術的綜合創新設計的產品!軟體產品是計算機綜合技術的藝術品。就像你認識英文字母卻無法寫出相對論一樣!
-
3 # BrantGong
我給你舉個類比的例子吧。我經歷了好幾家公司,大領導都是要求下屬彙報要簡單明瞭,幾百字以內,最好是用圖表之類的形式來展現。
如果只是彙報結果,比如說經營賺錢還是虧錢,這倒還好。如果要解釋為什麼,基本上幾百字根本搞不定。所以我們基本上報喜不報憂,省了解釋的成本。
同比程式設計。入門的話,我覺得你要是能把excel的函式玩的6,對於外行來說,基本上很不錯了。再高階一點,宏命令。如果這都能搞定,不如去學python?
-
4 # ftdxiao
難道不是語言,是思維!用筆在紙上畫畫誰都會,但要畫出藝術作品,就不是人人能做到;把鋼琴按出聲誰都會,但要彈出樂曲就不是人人能做到;用筆寫字誰都會,但要寫出好的文學作品,就不是人人能做到。計算機語言只是工具,學會計算機語言只是會寫字,會畫畫,會把琴按出聲,所以程式設計難的不在於語言。
-
5 # 哪是剎車
其實除了比較底層語言(例如彙編、C等),幾乎所有上層語言本身都不難,語法、關鍵字就那麼幾個,幾小時還記不下來?邏輯、迴圈語法即使非程式設計師也不難看懂。然而還是有人覺得程式設計難學,難在哪?我個人覺得難點可能包含以下幾點:
解決問題的方法不清晰,無法分解成程式語言不懂資料結構,不知道如何用資料結構來描述一個事物對於執行環境不熟悉,不知如何與使用者、系統互動對於第一點和第二點,不少圖形化程式設計透過封裝成解決方案,以 UI 或元件的形式提供給開發者,似乎是一個非常不錯的解決方案,比如 RGB 變數的分離與合併操作:
Blender 中的分離RGB與合併RGB
然而,對於開發者來說,如果不知道 RGB 是什麼,其實還是無從下手。
其實大多數程式設計師在程式設計的過程中,打交道最多的,並不是語言本身,遇到的難題大半也不是語言本身,而是各種資料結構、介面、執行環境和事務邏輯問題。
其中資料結構 這是個無法繞開的基礎知識,不論解決什麼問題,基本上都是運用資料結構+邏輯程式碼來解決的。上層語言的資料結構比較簡單,最起碼也要把幾個常用的結構入門吧?
後面三個問題道是可以使用封 API、元件等方式提供給開發者,但仍要學習 API、元件文件,好知道怎麼呼叫吧?
而有些難點呢,其實就是解決問題的思路上了,我打個比方:經典的老鼠試毒藥問題1000 個小瓶,其中一瓶裝著毒,其它瓶子全是水,可以在 24 小時內毒死一隻小老鼠問1:用什麼方法找出有毒的那瓶藥水?問2:如果只給24 小時間找到毒藥,最少用多少隻老鼠?
解1,看起來很好辦,迴圈一千次,每迴圈一次拿一瓶藥水喂老鼠,等 24 小時看老鼠死活不就得了?
這是沒有深入研究就能得出的解決方案,好在不需要動腦子;缺點是迴圈一次就要等24小時,最差的情況下幾乎要等三年才會有結果。誰能接受?老鼠都要老死了……
解2,看起來也好辦吧?給我一千隻老鼠,每隻幹一瓶,24 小時內就會出結果,那答案就是 1000 只老鼠嘍?好傢伙,挨瓶喂完這一千隻老鼠,要多少人?要多少時間?
而問題2的最佳答案:24小時內最少用10只老鼠就能找出毒藥。解題思路略長,我這就不發了,有興趣就自己找找看吧,簡單說就是巧妙地使用二進位制原理來解題。
而這種思路,其實和語言本身也沒關係,而是對於開發者自身的基礎知識、邏輯能力、演算法能力的要求,而這些確實不是短時間內能建立起來的。
所以語言本身並不是程式設計的門檻。上面說的這些才是,有些問題目前並不能透過工具來極簡化,還是得學的。
-
6 # 日衝資訊 黃
Excel就是,它的學名叫Spreadsheet程式語言。配上VBA(您可以把它理解為底層介面)、接外掛,Excel可以說是無所不能的。
-
7 # 黃錦150
程式語言其實是不難的,難的是要解決的問題本身。學會語言只能說你能熟練使用這個工具,但是最終目的是要解決問題。
-
8 # 文兄君
學會和活用是兩個概念,學會真的不難,語法關鍵字就那麼些,外面培訓班什麼三天入門七天精通的比比皆是,分分鐘寫個氣泡排序之類的。
但是活用呢?就有意思了,解決實際問題從來不是靠學會的語法,這就像是我會說英語和我會用英語來處理人情世故一樣的道理。
回覆列表
程式語言難嗎?說實話程式語言不難,一點都不難。從83年自學basic至退休後自學Python,基本都是兩個星期就可搞定,沒有感覺到難。
你說的難,應該是如何應用程式語言去處理實際問題,那麼這就和你的學識密切相關了,這就像同樣一支筆,在你的手裡和在文學家、畫家等的手裡,它所呈現出的最終結果各不相同是一樣的。