[ergocoder]

To be fair, to learn to think, you have to learn the language first.

Learning to program without knowing the language is useless and counter-productive.

Of course, this doesn't mean you have to learn 10+ languages first... but you have to learn a real programming language (not a toy one) before you can learn to program.

Edit: * a language

[Jtsummers]

> To be fair, to learn to think, you have to learn the language first.

Which language is the language? A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately (with some exceptions that push outside the normal algorithmic language notation of the Fortran, C, Java, JS, Common Lisp, Rust, Go, etc. family of languages; but those are minority languages and a competent programmer shouldn't need more than a short period of time to become literate, if not expressive, in it).

[ergocoder]

I meant "a language". Corrected it.

> A competent programmer can think about programming and reason about programs written in most languages without having to know that particular language intimately

That's because the programmer already learned how to program.

But when they started, they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.

[Jtsummers]

> they definitely didn't write only pseudocode that wasn't runnable (to see the results) for months/years.

GT started students that way and it worked well for years. A full semester (number varied, but was the CS 101 course, 1301/1311/1501 or something like that), taught with only pseudocode. They got rid of it because of appearances, trying to be like every other school out there. Eventually settling on Python, I think, after a brief stint with Scheme (which ended after a major cheating scandal).

[wanderingmind]

This, we learn natural language like English first before we can use it to express ideas, argue for or against those ideas with evidence. The problem is not teaching a programming language, the problem is stopping there and not teaching how to use it to solve real problems.

[jmalicki]

Bullshit.

You need to learn to leetcode in psuedocode first.

[ergocoder]

Bullshit.

I never see anyone learning to program using pseudocode (which isn't runnable to get feedback).

If they used pseudocode, were they just run the program in their heads?

[gregjor]

In The Art Of Computer Programming, one of the most influential and comprehensive series of books on the subject, Knuth uses a fictional assembly language called MIX in the examples. The reader does "just run the program in their head."

In Software Tools Brian Kernighan and P.J. Plauger describe a pseudo-language called RATFOR (Rational Fortran), and then throughout the book implement RATFOR in itself.

Getting feedback while learning to program has a lot of value, but so does learning to think through code in your head. People old enough to remember when you had to wait a day to run your program and get results back (very slow turnaround) know the value of that skill, we used to call it "desk checking" -- reading through your code and running it in your head and on paper.

[disgruntledphd2]

The newer versions use MMIX which is much closer to ARM assembly.

There's a compiler plugin for gcc, and when I worked through volume 1 I did type the code in and run the exercises.

I found it incredibly useful, but obviously YMMV.

[ergocoder]

Sure it is useful to run code in your head. I didn't say we must not think through code.

But to unable to run actual code at all? Come on. Who learns programming that way?

[gregjor]

I don't think anyone suggested that.

[jmalicki]

I suggested that. You should be able to look at algorithmic code and prove it correct without worrying about running it.

[rramadass]

> But to unable to run actual code at all? Come on. Who learns programming that way?

Edsger Dijkstra was a proponent of that approach i.e. develop program and proof by hand in a language for which there is no compiler/interpreter.

I wrote about it here - https://news.ycombinator.com/item?id=47985605

[Izkata]

> were they just run the program in their heads?

This is itself a skill people need to learn, that I'm not sure is possible with pseudocode and no prior experience. Too easy to gloss over details without actually running it to learn where your blind spots are.

I did this workshop a decade or so ago where I learned my co-workers don't do this, and never did learn how they understand code otherwise. One of them mentioned he didn't even realize this was a thing.

[jmalicki]

> never did learn how they understand code otherwise.

This particular statement interested me.

In code review, I always am a stickler that "if I need to run the code in my head to prove something about it for me, I want to see that in a unit test - I shouldn't have questions about the code that aren't already answered by the tests"

[linguae]

When I took an introductory programming class at Sacramento City College in fall 2004 during my senior year of high school, we spent the first half of the semester designing our programs using flowcharts and pseudocode. We were encouraged to check the logic of our flowcharts and pseudocode. In the second half of the semester, we implemented those programs in C++.

I haven’t seen this pedagogical practice in any other introductory course I’ve seen since. I believe it’s a holdover from the early days of computing, when programmers didn’t have access to personal computers or even interactive computing, which meant that programmers needed to spend more up-front time on design. Think of the punchcard era, for example.

I teach introductory programming in C++ at Ohlone College in Fremont, and I have my students write C++ on Day 1, starting with “Hello World” and going from there without flowcharts.

[dataflow]

I think it's for all intents and purposes impossible to program like this in this century. Like imagine just writing x + y in C++. Are you seriously going to enumerate every declaration of operator+ in the translation unit in your head to see if it's eligible (don't forget ADL)? And then every single possible implicit conversion or promotion that could make other ones eligible? And then go through all the overload resolution rules that practically no humans have memorized (with any template instantiations that may come into play) to figure out if the declaration you wanted is actually the best match? That's before you even look at its definition...

[ranger207]

In one of my classes they had to explicitly ban people from using Python in their psuedocode submissions lol. (Generally this meant things like "no list comprehensions" and similar Python syntax details).

[dnnddidiej]

/s

?

[jmalicki]

Not at all. It's called learning computer science. Just like you can do calculus without simulation, you can understand the semantics of a computer program without running it. It might make it harder, but running it is only a didactic tool - as Knuth did, you should be able to prove it correct without ever running it.

[dnnddidiej]

Yes but not everyone learns like that. Some people need to feel something before learning the theory. It makes the theory easier to digest.