我們不先教孩子演算。我們首先教他們算術，然後是代數，然後是幾何，解析幾何，然後是微積分。Framework/IDE知識陷阱
那麼，爲什麼我們先教計算機科學家的框架和IDE呢？有些課程確實迫使學生學習計算機科學的基礎知識，但是我看到的絕大多數畢業生不能構建自己的框架來挽救他們的生命。
那麼下一代工具製造商又在哪裏？
我們如何促進創建框架和開發環境所需的理解？
這當然是一個普遍性。並不是所有的教育都缺乏，但它似乎是絕大多數，它降低了我們整個職業的質量。
我認爲這個比喻有點偏離。一個更好的比喻是「我們不教孩子們使用計算器來增加和減少，爲什麼教程序員使用IDE來編程？」
擺脫需要X年Y經驗的人力資源部門。大學只根據人力資源部門的要求量身定製課程。
我聘請畢業生誰可以編碼的東西（我真的不在乎什麼語言）和誰可以學習。
我明白你的觀點，儘管我認爲數學比喻不太合適。你有有知道基本的算術能夠在任何其他數學學科得到任何東西。
當我開始編程框架時，大多是聞所未聞的。如果你想要一棵二叉樹，就由上帝，你去寫了一棵。在C或彙編程序中。基本上就是這樣，爲了完成任何事情，你必須知道很多。今天，框架和IDE以及設計人員使得「noobs」可以在不知道如何構建框架，編譯器或管理內存分配的第一件事情的情況下創建實際上非常精彩的事物。
真正的問題是，那些認爲自己很棒的dingbats，優秀的程序員是因爲他們使用了Frontpage還是Access？管理者很難說出那種程序員和真正的知道作爲一門學科的軟件開發之間的區別。
那麼，具體來說，這是爲什麼呢？因爲每個人都想要一份工作，而且沒有人聘請知道如何構建二叉樹的程序員。他們希望程序員知道.Net或J2EE等。
我曾經爲一家有兩個開發組的公司工作。一個叫做「核心」，爲另一個組織建立了工具。另一組是將核心工具組裝成功能的「代碼猴」。我們發現後者從未表演過。無論如何，核心團隊完成了大會的90％。 – dacracot 2008-11-06 18:45:55
我認爲對於9到5位程序員來說，可能已經有足夠的工作了，他們可以從框架層開始並從那裏開始。無論如何，真正好的 - 大多是作爲職業和/或計劃的愛好 - 的程序，將會獲得他們在大學中可能錯過的知識。無論你教什麼課程，你都不能強迫每個人都成爲一名優秀的程序員。好奇的學生將會了解其基礎知識，無論是在課堂上教給他們，還是完全依靠自己。
儘管如此，聰明的人仍然會學習。但是，很難學習DFAs或NFA或LALR解析「在工作中」 - 這些都是我在「工作中」使用的所有東西。 – Bevan 2008-11-06 20:33:31
在編程時學習抽象比學習細節要容易。教某人手動編碼彙編程序打印「Hello World」比讓他們將一個帶有按鈕的表單放在一起，當按鈕被點擊時顯示「Hello World」消息更難。
在學習駕駛之前，你不知道如何構建汽車發動機，是嗎？因爲駕駛沒有必要。同樣，您不需要了解鏈表或二叉樹如何工作以維護名稱列表並搜索它們。
總會有那些想要深入瞭解事物「爲什麼」的人，但我不認爲需要完成任務。
當事情沒有按計劃進行或沒有我擔心的功能不可用時。淺層知識開發人員無法轉向。 – dacracot 2008-11-06 18:52:01
是的，他們轉向深思熟慮的開發人員。並不是團隊中的每個人都必須非常出色。事實上，這有時是一件壞事。每個團隊都需要Do-Bees。 – 2008-11-06 19:07:14
我總是通過詢問難以回答的問題來篩選應用程序，他們只有在他們明白事情真正起作用的情況下才能回答。我認爲這是一個真正的恥辱高校正在教人們基於框架的開發，但不關注核心軟件原則。我同意最重要的是懂得編程如何工作，並且有能力學習任何事情的人。
我所知道的大多數大學都有一門計算機編程課程的介紹，教授基本的編程概念。不幸的是，如果不實際編寫代碼就不可能編程。
問題是，有些人喜歡使用一些OO語言（如JAVA或C＃）來教這門課程，因此學生必須使用Visual Studio（或Java等價物）。 當IDE強迫你以某種方式工作時，很難解釋這些基本概念。
我認爲第一語言的學生學習應該是C這樣的函數式語言。這樣，他們和基本的CS概念之間的抽象層就少了。
同意cfeduke。
我看了2年前做過的同一個CS課程的工作，而且他們更加努力。 5年前，方式方式更難。
CS欄越來越低，大概是因爲越來越多的工作不需要任何複雜的CS主題的任何工作知識。有很多人只是裁減代碼就業。
既然傳統意義上的人想成爲程序員做CS課程，但編碼變得更容易，這仍然是這樣。
真正需要發生的是CS到而不是是專業軟件開發的要求。相反，還需要有另一個課程，更多地關注讓人們走出門外，切入代碼。
這會讓CS變成變成那當然是你下一代的工具製造者。
有工具製造商和工具斷路器。當然有工具，但我們不要去那裏。
如果你對汽車車間有一個很好的看法，你會看到很多有趣的小工具，你沒有在五金商店的貨架上看到。就像推回制動鉗活塞的那樣。或用於壓縮閥杆的夾具，以便您可以在與同伴談論釘釘新祕書（而不是在彈簧從您的螺絲刀上滑出時觀察它們飛過房間）的同時用一隻手拿到夾頭。
這些是由機械師設計的。他們真的很有效，一般很小，而且很便宜，而且直到你看到他們在行動之前，他們完全無法理解。
汽車技術的大部分深刻變化是自下而上的，但自上而下也是需要的。個別機械師無法進行基本的技術變革，如從鑄鐵切換到合金頭。一把新掃帚清掃乾淨，一把舊掃帚知道角落。你需要兩個。
但我離題：關鍵在於如果機械師缺乏基本的技能和知識，他們就無法設計這些工具。我小時候父親用廢鐵製造了一整輛摩托車。作爲一名成年人，由於我缺乏他的技能和知識以及思維模式，我幾乎無法保持我從本田買到的自行車，更不用說像T先生一樣在充滿創造力的狂熱中接受它。
有了代碼，我就像我的父親是鋼鐵一樣。 Donald Knuth是我的不變夥伴，當我們的GPS記錄器的無線協議需要在.NET中實現時，它就是我所見到的。小部件猴子不知道從哪裏開始。
我認爲問題實際上是一般的GUI範例。
微軟用計算機制作得容易得多，他們推廣了圖形用戶界面。他們將這個接口隱喻（桌面，文件）帶到了編程領域，並且非常有效地使用他們的Visual Basic工具。
但正如GUI掩蓋了「引擎蓋下」發生的情況一樣，IDE也掩蓋了對位和字節的操作。當然，問題在於回報率的風險 - 程序員在生產率方面失去了多少理解？
粗略看一下「計算機編程的藝術」可能會說明IDE爲何有用; 「當我們有1位的項目時，最終的包裝密度是可以達到的，因爲我們可以將64個單詞填入一個64位的單詞中。例如，假設我們想要一個所有奇素數小於1024的表，所以沒有問題;只需要八個64位數字：
p0 = 011101101101001100101101001001001100101100101001000101101101000000 p1 = ......「編程非常困難，您可以看到IDE如何提供幫助。 ：^）
絕對是問題的一部分。 – dacracot 2008-11-06 18:42:55