Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helping my students overcome command-line bullshittery (2014)

pgbovine.net

Post reply on HN
Print view View original

151–160 of 168 posts

Re: Helping my students overcome command-line bullshittery (2014)

#151

Post by mikekchar »

a_bonobo wrote: post #70
mikekchar wrote: post #60

I think the author is running afoul of a very common problem (albeit he seems to be slightly more aware of it than most): "Ease of Use" and "Ease of Learning" are two different, and often incompatible goals. He praises the command line utilities as offering productivity improvements of an order of magnitude or more, but then castigates is for not having changed in half a century. His description of the 2 cultures of…

> nobody has found a better way to do it. People have found a better way to do it! It's just that research software ignores the better way because it's mostly "proof of concept", once the paper is out, who cares who uses it, that's not my department. The incentive is to publish, not to create usable software . In fact, spending the time to make your software usable is wasted - no funding committee, no tenure committe…

Hmm... We don't seem to be connecting here. When I said "there is no better way to do it", I meant that interacting with tools through the command line (or shell scripts) is the best way we have of doing these kinds of tasks. I didn't say so explicitly, but my intention was to include all of the usual tools that one would use (grep, awk, make, whatever).

Though it was several decades ago, I also suffered greatly from having to deal with poorly built academic projects. It's not even confined to academia. A friend of mine often tells a tale of a start up who spent 3 years building software only to discover that they had built such a mess that they couldn't deploy (never having done it in 3 years... :-P). The company ran out of money before they solved the issue.

I may be wrong, but I don't think that's what the original article was complaining about. I think he was frustrated that while the tools were very good, they were hard to teach to his students. He wishes there were easier to learn systems for doing this work.

Personally, I don't think it will ever happen because the problem space is quite complicated. You can make it easier to learn by restricting what it can do, but eventually you butt up against that ceiling, making it extremely difficult to use. That's why we are all still using these same tools decades years later (although, I'm quite happy to ditch make in favour of more modern equivalents [1])

I can't tell you the number of times I've wandered into a new project and spent every spare second writing README files, fixing the build systems, removing dead code, etc. I've even worked on projects where there wasn't a single person who knew how to build the entire project -- all they could do was compile individual files and link it to pre-built libraries. They thought me crazy for even wanting to know how to build it. We do our industry a grave disservice by not teaching this stuff somewhere in our education system.

[1] Says the guy who just wrote a new make file a couple of weeks ago

Re: Helping my students overcome command-line bullshittery (2014)

#152

Post by mamcx »

Gibbon1 wrote: post #76
opnitro wrote: post #26

Earlier quoted context omitted.

I've always had people who wanted to learn programming become so bogged down in the tools around programming. It led me to thinking that it might be better to teach the fundamentals with pen/paper/whiteboard. To get the "this is why programming is important/powerful" message across. Anyone tried this/had any success with it?

I have a small anecdote about this. In the last couple of years I've had few people ask me 'how can I write a program with a GUI.' And I give the advice, 'Download the free version of Microsoft Visual Studio for C# and select new project, windows forms' and then start mucking around. All of them were convinced by others to use qt and C++ All of them gave up after a week or two of no progress.

I start with FoxPro DOS (2.6). After the end of the 3 months course, a full app with menus, forms, reports, etc. The same with Acces. Later Delphi (the best RAD ever!). In contrast, Visual Studio is clumsy.. but all others tools fall so far below than people truly imagine html+js is easy!

Re: Helping my students overcome command-line bullshittery (2014)

#153

Post by 32bitkid »

dexiwz wrote: post #96
32bitkid wrote: post #23

While I completely agree with the gist and point of the the article, the word "bullshittery" is a bit over-the-top. I grew up in the suburbs of Detroit and in middle school and high school there was an abudance of shop classes; wood shop, metal shop, electronics, auto shop. In first-year wood shop, we started out with a little coping saw and a file and made golf tee holders and bird houses out of soft pine. After a w…

This analogy falls flat when you compare the levels of Unix 'bullshittery' to a shop. In a shop you have a limited number of already working machines that are readily visible. In Unix, you not only have to know how to use the machines, but how to install them, how to repair them, how to select similar, yet slightly different ones, how to copy your machines and make them run the same way in a different location. And o…

Of course, the analogy falls down–like all analogies–at some point. However, there is a whole realm of industrial fabrication beyond what is available at a simple/hobby shop.

To put it a different way: there are tools that I want to use when I am making one of something. Then there are different tools when I am making 10 of something. Again at 100, 1,000, and 1,000,000.

I've been a teacher, and I think there is a inherent conflict: As a teacher, I want my students to learn _how_ to do something, but I also want them to do things "right". Those two goals are often at odds. Sometimes the best way to learn is to do it "wrong"; preferably in a safe environment where doing it wrong won't kill/maim you. I think the injustice is trying to teach students how to use the "for a million" tools (which they will _need_ later), when they really struggling with the idea of making one.

Re: Helping my students overcome command-line bullshittery (2014)

#154

Post by a_bonobo »

mikekchar wrote: post #151
a_bonobo wrote: post #70

Earlier quoted context omitted.

> nobody has found a better way to do it. People have found a better way to do it! It's just that research software ignores the better way because it's mostly "proof of concept", once the paper is out, who cares who uses it, that's not my department. The incentive is to publish, not to create usable software . In fact, spending the time to make your software usable is wasted - no funding committee, no tenure committe…

Hmm... We don't seem to be connecting here. When I said "there is no better way to do it", I meant that interacting with tools through the command line (or shell scripts) is the best way we have of doing these kinds of tasks. I didn't say so explicitly, but my intention was to include all of the usual tools that one would use (grep, awk, make, whatever). Though it was several decades ago, I also suffered greatly from…

I appreciate your post!

I do agree that awk, grep etc. are extremely good tools, and you rarely run into real annoyances with them (actual scientific software is a completely different bag of problems that suffers from different problems). Still, there's lots of room for improvement even in the good tools [1] and I feel like it's easy to stop thinking about the problem space, and shut out others who don't immediately grok what's going and why you've now run "apt-get update" instead of "apt-get upgrade". Many posts in this thread show that attitude.

I do think at some point we'll get easier systems - git has now overtaken cvs in popularity so these tools aren't set in stone, even though both aren't easy to understand for beginners, git is just more powerful. I see people write tiny Python scripts instead of using bash-tools to manipulate folders and files, I think that is a case of taking up a tool because it's easier to use. Are there other tools that are slowly fading out? I feel like awk is on the way out but that may be my echo-chamber.

>We do our industry a grave disservice by not teaching this stuff somewhere in our education system.

I fully agree - I think that some hands-on programming, understanding and refactoring experience is much more important than knowing how to write the code to keep a b-tree balanced. The first is something you have to do every few weeks - the latter is something you do only once or twice, if ever (even though it's a cool application of recursive thought). The first will make you a more valuable member of the workforce.

[1] One example: when I teach people git I struggle to show the man-pages because nothing in there makes sense until you've truly understood how git works under the hood

Re: Helping my students overcome command-line bullshittery (2014)

#155

Post by tptacek »

marvy wrote: post #134
tedunangst wrote: post #56

Earlier quoted context omitted.

> whatever it is strcspn does. It deletes the new line from the end of the string that fgets() insists on including, even though nobody anywhere has ever wanted it. :)

Don't write things like that, people might believe you. That is not at all what it does. http://www.cplusplus.com/reference/cstring/strcspn/

I don't think he's being entirely serious, but you obviously can use it that way:

  char foo[] = "this is a test\n";
  foo[strcspn(foo, "\n")] = 0;

Re: Helping my students overcome command-line bullshittery (2014)

#156

Post by gtrubetskoy »

distrill wrote: post #61
gtrubetskoy wrote: post #34

He makes a good point. I once tried teaching my two teen-age kids Python. I was surprised to discover that before we could get into any Python I had to explain all kinds of things I took for granted (or, perhaps I don't remember how I learned them) - what is terminal (this is OSX), what is the command line, why it's called "shell" and what is the kernel, what is the current directory, what are text files, how to edit…

I'm in my fourth year of a computer science degree, and there are students graduating with me in a few months who have never written code outside of eclipse. They've even had us 'deploy' a website with filezilla. It obviously works well enough for the size of projects we were dealing with, but I can't help but be a little put off by how unfamiliar/uncomfortable most people (in most of my classes) are with the command…

Very curious - what is the name of the school you're attending?

Re: Helping my students overcome command-line bullshittery (2014)

#157

Post by nostrademons »

netheril96 wrote: post #150
nostrademons wrote: post #108

Earlier quoted context omitted.

I'm curious - what's your motivation for being interested in tech? Have you given some thought about what drives you? I've found, personally, that my motivation has changed fairly dramatically over the years, and with it, my perspective on high-level vs. low-level programming. When I was in high school and college, my motivation was that I wanted to feel competent - I wanted a skill that was all my own, that I could…

> Frontend devs frequently make more than backend devs, and have many more job opportunities to choose from. Out of curiosity, how true is this statement? I hear from my friends that most frontend devs start with higher salary, but have a hard time climbing the corporate ladder, especially if the frontend is not the core competency of the company. I wonder which one is a more accurate depiction of reality.

Both statements are true. The market for frontend devs is both competitive and very liquid: there are many job opportunities and many frontend developers. As a result, starting salaries tend to be high, and you can very quickly "rise to what you're worth": if you don't like your boss or your company is underpaying you, jump ship.

However, frontend tech tends to expire every 5 years. This is part of the reason why starting salaries are high: junior developers can compete effectively with senior ones. If you go backend, you tend to amass a steady stream of domain & infrastructural knowledge about the company which makes you significantly more valuable to them over time. Raises and promotions follow, even if that knowledge is of limited usefulness on the open market.

Whether you'd prefer one or the other partially depends on how you would like to manage your career. The OP in this subthread indicates that he's drawn to the craftsmanship, the idea of steadily making something better over time, and this style tends to suit backend dev better. I tend to be drawn toward discovery, the process of finding loopholes & gaps in the market and filling them with new solutions, so for me frontend & entrepreneurship is more useful. (Frontend dev tends to be a more useful skill for founders, because almost every startup needs an appealing frontend but most can get by with a half-assed backend until they hire more engineers. Witness DropBox vs. Tarsnap - they came out at the same time and both use AWS for storage, but DropBox built a beautiful frontend and a minimally-functional backend, while Tarsnap barely built a frontend at all but has the most sophisticated secure backend I've seen in a product.) For me, the idea of climbing the corporate ladder sounds like hell, while to other engineers on this site, the idea of retraining in a different technology every 5 years probably sounds like hell.

Re: Helping my students overcome command-line bullshittery (2014)

#158

Post by zem »

ddingus wrote: post #133
zem wrote: post #123

Earlier quoted context omitted.

right, but it needs to be done again by the single person maintaining the automation tools, who presumably is more of the "programmer" than "user" inclination. everyone else in the lab benefits.

And who is that exactly? For long established, regularly used tools, there is a case for funding this activity somehow. For the many specialized tools? I'm not sure how this would actually happen, unless the person who creates it decides to maintain it. When their career focus doesn't value that tool, we can't really expect anything. Worse, let's say some established systems exist. They have a barrier to entry in tha…

i meant, if there is an organisation (the OP's example involves a university department, but this holds for other places too) where the majority of people simply want to use computers to get their work done, it is well worth having one person (or a team, as things scale up) whose job is to automate all the incidental details of working with the operating system and environment, so that people don't have to context switch from a "user" to a "programmer" perspective all the time.

Re: Helping my students overcome command-line bullshittery (2014)

#159

Post by marvy »

tptacek wrote: post #155
marvy wrote: post #134

Earlier quoted context omitted.

Don't write things like that, people might believe you. That is not at all what it does. http://www.cplusplus.com/reference/cstring/strcspn/

I don't think he's being entirely serious, but you obviously can use it that way: char foo[] = "this is a test\n"; foo[strcspn(foo, "\n")] = 0;

Sure you can do that, but strcspn only found the newline, it didn't delete it. After all, you can also do

foo[strlen(foo)-1] = 0;

But I don't think anyone would say strlen modifies the string.

Re: Helping my students overcome command-line bullshittery (2014)

#160

Post by tptacek »

marvy wrote: post #159
tptacek wrote: post #155

Earlier quoted context omitted.

I don't think he's being entirely serious, but you obviously can use it that way: char foo[] = "this is a test\n"; foo[strcspn(foo, "\n")] = 0;

Sure you can do that, but strcspn only found the newline, it didn't delete it. After all, you can also do foo[strlen(foo)-1] = 0; But I don't think anyone would say strlen modifies the string.

You just chopped the last non-NUL character off that string whether it was a newline or not.
Post reply on HN