4 ms·

Learning how things "actually" work is different than learning how to get things done. There is definitely room for learning how things work "under then hood".

Learning how things "actually" work is different than learning how to get things done. There is definitely room for learning how things work "under then hood". Aka algorithm work, creating your own bubble sort, creating your own blog, etc. Those skills get added to your list of tools. Understanding which sort is best for which application... which language... which paradigm. If you don't learn the different things, you become a programmer that uses a hammer for a solutions - because it's the only tool you know. Granted, I may have been a bit harsh - it's hard to do sarcasm, tone of voice, etc in text message. So take my post with a grain of salt :)

vetinari 10y ago
> Learning how things "actually" work is different than learning how to get things done. And that's how you get C++ programmers who don't know, what is a linker and what it does. Their IDE presents them a project organized in a tree and when then press "Build project" button, an exe is on the other end.
- wernercd 10y ago
  That's an important point of learning C++... and one I would agree needs to be learned for that level/line of programming. Does a Web Developer or a LoB developer (which is mainly my pervue) - who is never going to go that deep - need to know linking and header files? That experience is vital for C/C++... but for PHP or Javascript? I've always meant to learn a little more of C/C++ and maybe even learn some Assembly - but in my years of work I've never personally NEEDED that knowledge to get paid. As a .Net/C# programmer, I've only touched those lower levels as an educational exercise or many years ago during entry level classes I've since long forgotten. All of my important work has been in two core places: SSMS (or a couple other database IDEs) and Visual Studio (2005 through "15"). I've never used the command line to build a project - although I know that exists. Does that make me a bad programmer? I don't think so. That would be a different answer if I was a C/C++ programmer.
  - Symbiote 10y ago
    > I've never used the command line to build a project That means you probably couldn't, for example, write a small script that, for each of the last 10 commits, compiles the project and runs the tests -- to see where a bug was introduced.
    - wernercd 10y ago
      Well, considering my last few jobs don't enforce tests that is a shortcoming of mine I'll admit too freely. My current job is a new batch of programmers (all at the company less than a year and me the newest) that introduced SVN, a dev environment, Nugets and a build system (Jenkins). Needless to say the code that we are working with involves more WTFs than you can shake a stick at and testing is down the list, unfortunately. I have no doubt I could figure that sort of system out but it would definitely be a challenge for me. There any good demo's of that sort of setup and learning how to navigate it?
      - Symbiote 10y ago
        I haven't done any development on Windows for almost 10 years, so I don't have an opinion on Nugets. Git seems more popular than SVN, but SVN is simpler to use. Jenkins is very widely used by Java developers, especially, but works with other languages. At least for Java, it builds on the command-line approach of Maven (a build tool), since it essentially runs commands like "mvn compile" "mvn test" in sequence and reports the result -- exactly as a developer would, either by typing them or pressing a button in the IDE. Version control, a development environment, dependency management and a build server are all sensible parts of continuous integration (i.e. having automatic builds of the software which run the tests, to avoid introducing new bugs and mean the software is usually in a state where it can be demonstrated to the boss, or released). "Continuous Integration" (book [1]) is a good general guide, which helped me explain what the benefit of these tools would be to a reluctant team in a previous job. - I have sat near to developers using Windows, and I think the typical Linux (especially) "command line first" approach has significant benefits for any developer. Some one-off problems can be solved very quickly, and the solution is usually repeatable and can be automated. Last week's issue was ~10000 identifiers, of which about 10 were known to cause an error in our REST API. The logging wasn't sufficient, but it was easy to make the read-only API call with every identifier: I began with a single identifier: curl -Ss http://api.example.org/get/1234 (retrieves the content of the URL) Then made the test: curl -Ss http://api.example.org/get/1234 | grep SUCCESS || echo "Problem with record 1234" (finds any line containing "SUCCESS", returns true if found, false otherwise) Then saw that I could read my identifiers (in reality, they were output from another command rather than read from a file): for i in $( cat identifiers ) ; do echo $i done Then tied it all together: for i in $( cat identifiers ) ; do curl -Ss http://api.example.org/get/$i | grep SUCCESS || echo "Problem with record $i" done Of course, this could be done in many languages (even Excel), but it's hard to beat shell script for development speed, and with the bug fixed we don't need to run this check again. Last month, it was which of 100,000 ZIP archives contains invalid TSV data (wrong number of columns, should be 50) for i in *.zip; do unzip -p $i output.tsv | tr -d -c $'\t\n' | awk '{ print length }' | grep -v '^50$' && echo "$i corrupt" done (i.e. unpack only output.tsv, discard everything that isn't a tab or newline, print each line's length, then look for lines that aren't "50" and report.) It's not the tool for everything: I wouldn't try and process XML, and CSV files with quoted commas would be better handled with a proper library, but hopefully that's an idea of some strengths. For the specific task I mentioned (finding the bad commit), semi-pseudocode is for c in $( svn print-out-last-10-commit-identifiers-from [repository] ); do svn checkout --revision $c [repository] $c cd $c mvn compile test || break done [1] https://books.google.dk/books/about/Continuous_Integration.html?id=PV9qfEdv9L0C https://books.google.dk/books/about/Continuous_Integration.h...
0xCMP 10y ago
Grain of salt taken :) I've got personal experiences which says IDE-first is a bad approach. However, once you've learn the basics you should definitely graduate to an IDE as a student like you say. My experience has been that many students don't learn a single thing well enough to build upon to gain those extra tools you mentioned. An IDE might bring them closer to that point faster, but I also think it makes them leave things behind they should know. (recent graduate, informal teacher to many friends getting in to CS industry)
- wernercd 10y ago
  It's definitely a part of getting a well rounded education... but a large part depends on WHAT you are learning. What's needed to learn C/C++ is different than what's needed to learn Javascript. C#. Ruby. PHP. SQL. Etc... A Javascript developer could spend his/her life without ever touching a compiler. I've spent my "career" without ever needing that level of knowledge as a .Net Developer (C#/VB) and Sql Reporting guy (SSMS/Crystal Reports/etc). I would agree wholeheartedly that a C/C++/Assembly guy needs that experience... but most programmers don't need to know how a linker works.

vetinari 10y ago

> Learning how things "actually" work is different than learning how to get things done. And that's how you get C++ programmers who don't know, what is a linker and what it does. Their IDE presents them a project organized in a tree and when then press "Build project" button, an exe is on the other end.

wernercd 10y ago
That's an important point of learning C++... and one I would agree needs to be learned for that level/line of programming. Does a Web Developer or a LoB developer (which is mainly my pervue) - who is never going to go that deep - need to know linking and header files? That experience is vital for C/C++... but for PHP or Javascript? I've always meant to learn a little more of C/C++ and maybe even learn some Assembly - but in my years of work I've never personally NEEDED that knowledge to get paid. As a .Net/C# programmer, I've only touched those lower levels as an educational exercise or many years ago during entry level classes I've since long forgotten. All of my important work has been in two core places: SSMS (or a couple other database IDEs) and Visual Studio (2005 through "15"). I've never used the command line to build a project - although I know that exists. Does that make me a bad programmer? I don't think so. That would be a different answer if I was a C/C++ programmer.
- Symbiote 10y ago
  > I've never used the command line to build a project That means you probably couldn't, for example, write a small script that, for each of the last 10 commits, compiles the project and runs the tests -- to see where a bug was introduced.
  - wernercd 10y ago
    Well, considering my last few jobs don't enforce tests that is a shortcoming of mine I'll admit too freely. My current job is a new batch of programmers (all at the company less than a year and me the newest) that introduced SVN, a dev environment, Nugets and a build system (Jenkins). Needless to say the code that we are working with involves more WTFs than you can shake a stick at and testing is down the list, unfortunately. I have no doubt I could figure that sort of system out but it would definitely be a challenge for me. There any good demo's of that sort of setup and learning how to navigate it?
    - Symbiote 10y ago
      I haven't done any development on Windows for almost 10 years, so I don't have an opinion on Nugets. Git seems more popular than SVN, but SVN is simpler to use. Jenkins is very widely used by Java developers, especially, but works with other languages. At least for Java, it builds on the command-line approach of Maven (a build tool), since it essentially runs commands like "mvn compile" "mvn test" in sequence and reports the result -- exactly as a developer would, either by typing them or pressing a button in the IDE. Version control, a development environment, dependency management and a build server are all sensible parts of continuous integration (i.e. having automatic builds of the software which run the tests, to avoid introducing new bugs and mean the software is usually in a state where it can be demonstrated to the boss, or released). "Continuous Integration" (book [1]) is a good general guide, which helped me explain what the benefit of these tools would be to a reluctant team in a previous job. - I have sat near to developers using Windows, and I think the typical Linux (especially) "command line first" approach has significant benefits for any developer. Some one-off problems can be solved very quickly, and the solution is usually repeatable and can be automated. Last week's issue was ~10000 identifiers, of which about 10 were known to cause an error in our REST API. The logging wasn't sufficient, but it was easy to make the read-only API call with every identifier: I began with a single identifier: curl -Ss http://api.example.org/get/1234 (retrieves the content of the URL) Then made the test: curl -Ss http://api.example.org/get/1234 | grep SUCCESS || echo "Problem with record 1234" (finds any line containing "SUCCESS", returns true if found, false otherwise) Then saw that I could read my identifiers (in reality, they were output from another command rather than read from a file): for i in $( cat identifiers ) ; do echo $i done Then tied it all together: for i in $( cat identifiers ) ; do curl -Ss http://api.example.org/get/$i | grep SUCCESS || echo "Problem with record $i" done Of course, this could be done in many languages (even Excel), but it's hard to beat shell script for development speed, and with the bug fixed we don't need to run this check again. Last month, it was which of 100,000 ZIP archives contains invalid TSV data (wrong number of columns, should be 50) for i in *.zip; do unzip -p $i output.tsv | tr -d -c $'\t\n' | awk '{ print length }' | grep -v '^50$' && echo "$i corrupt" done (i.e. unpack only output.tsv, discard everything that isn't a tab or newline, print each line's length, then look for lines that aren't "50" and report.) It's not the tool for everything: I wouldn't try and process XML, and CSV files with quoted commas would be better handled with a proper library, but hopefully that's an idea of some strengths. For the specific task I mentioned (finding the bad commit), semi-pseudocode is for c in $( svn print-out-last-10-commit-identifiers-from [repository] ); do svn checkout --revision $c [repository] $c cd $c mvn compile test || break done [1] https://books.google.dk/books/about/Continuous_Integration.html?id=PV9qfEdv9L0C https://books.google.dk/books/about/Continuous_Integration.h...

0xCMP 10y ago

Grain of salt taken :) I've got personal experiences which says IDE-first is a bad approach. However, once you've learn the basics you should definitely graduate to an IDE as a student like you say. My experience has been that many students don't learn a single thing well enough to build upon to gain those extra tools you mentioned. An IDE might bring them closer to that point faster, but I also think it makes them leave things behind they should know. (recent graduate, informal teacher to many friends getting in to CS industry)

wernercd 10y ago
It's definitely a part of getting a well rounded education... but a large part depends on WHAT you are learning. What's needed to learn C/C++ is different than what's needed to learn Javascript. C#. Ruby. PHP. SQL. Etc... A Javascript developer could spend his/her life without ever touching a compiler. I've spent my "career" without ever needing that level of knowledge as a .Net Developer (C#/VB) and Sql Reporting guy (SSMS/Crystal Reports/etc). I would agree wholeheartedly that a C/C++/Assembly guy needs that experience... but most programmers don't need to know how a linker works.