Live data from Hacker News

If You're Not Writing a Program, Don't Use a Programming Language [video]

youtube.com

231–240 of 288 posts

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#231

Earlier quoted context omitted.

>Honestly I think it might be time to phase out teaching imperative and object-oriented programming. I have seen plenty of universities teach Java and C++, haven't seen any that teach actual OOP. James Coplien aptly calls the current paradigm "class oriented programming".

It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then…

To me, my intro to comp sci class nailed it by teaching Scheme. The first 30 min or so were spent introducing all the syntax wed learn in the entire class. The remaining several weeks were spent on CS concepts and learning to express ourselves to the computer. I've never used Scheme/Lisp professionally and nor do I have an urge to. But it was the perfect teaching language because it puts so little between the student and learning to program a computer.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#232
post #107

Earlier quoted context omitted.

Would you mind elaborating on "why separate address spaces connected by pipes are such a powerful abstraction", or point me to some sources? Likewise if there's something you can recommend for reading up on the Actor model?

CSP[1] is also related. For a quick breakdown of why CSP and the Actor model are both Good Ideas: Think about any concurrent system (i.e. multiple threads of execution). Any modification of a shared resource by one thread (one concrete example is a global variable, but filesystem, devices &c. all apply too), is implicit communication that can happen at any point whatsoever in another threads execution. The state of o…

Thank you for the insight. What you're describing reminds me pretty strongly of pure functions. Which I guess makes sense, since "Functional languages can do concurrency out of the box!!" (well yeah, but you need to learn how to write truly functional code first :D)

>"80% of the class didn't understand it, and the remaining 20% of the class thought that manual synchronization was not a problem"

Unfortunately it seems to be this way with many things in our field (/life?). And the 80% non-understanders group doesn't even stay the same people for every topic! :)

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#233
post #107

Earlier quoted context omitted.

Would you mind elaborating on "why separate address spaces connected by pipes are such a powerful abstraction", or point me to some sources? Likewise if there's something you can recommend for reading up on the Actor model?

Ya in my mind, executables that do one thing well and are connected by pipes is one of the most proven models for getting things done. Even relatively nontechnical people can write shell scripts, batch files and macros that take some kind of data from a socket/file/pipe, pass it through a bunch of black boxes and spit out an answer. This is very similar to the Actor model and is much simpler to reason about than the…

Thank you for the follow-up and the links! I wonder if your suggestion would hold if it were put to the test and one were to implement a big and complex software strictly with the independent processes+pipes model. I could well see that you would wind up in some other sort of hell, because the problem of understanding lies not in the way it's implemented but in the complexity of the tasks involved.

>Sorry this got a little long, I could ramble about the downsides of programming in these times for hours.

Haha, programmer talk is the best!

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#234
Don't have the chance to watch the video but highly disagree with the title.

Math as a language is just a DSL which carries a lot of historical burden that is not friendly at all. Programming languages can achieve same level of abstraction with more clarity. Math instead added too much specific syntactic sugar(bad is multiply(b, a, d), log a is log(10, a) or log(e, a)), operator overload (/ for divide and dy/dx for differentiation operator, same grammar for scalar and matrix multiplication, one of which is communicative while the other is not), and complicated design (integral would be much clearer if we write integrate(target=ax, over=x, from=0, to=10) instead of the original one).

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#235
post #234

Don't have the chance to watch the video but highly disagree with the title. Math as a language is just a DSL which carries a lot of historical burden that is not friendly at all. Programming languages can achieve same level of abstraction with more clarity. Math instead added too much specific syntactic sugar(bad is multiply(b, a, d), log a is log(10, a) or log(e, a)), operator overload (/ for divide and dy/dx for d…

The talk is about TLA+, which is somehow not a programming language, yet you follow a syntax and describe algorithms and then I'm not sure what happens.

Maybe you prove your algorithms and call it a day, or maybe you can ask your program to run it, like an external dependency.

It's very unclear how TLA+ is neither programming or how it fits in with your programming. But he is not asking you to do normal math notation.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#236

Earlier quoted context omitted.

You summed it up nicely. After writing my comment, I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software. So there will always be huge demand for that skill, and so colleges should probably continue building…

> I realized that imperative programming is so much more difficult than functional programming that in a way, it's the majority of the work of programming. Anyone can learn to use a spreadsheet, but it takes years of dedication to master debugging enterprise software. Anyone can learn to program spreadsheets, because spreadsheets realize that state is the most important thing, and puts it front and center—hiding the…

What you just said really struck a chord with me. I do tend to ignore state because it's less accessible. The result is that my code gets more esoteric and abstract while the changes I need to make to state come very slowly. On the other hand I've made spreadsheets as complicated as small applications I've made, but the cognitive load feels significantly lighter.

How can we bring state forward during development?

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#237
post #116

I'm more with Mike Acton in this respect; the hardware is the platform, not the software. And in that sense... In order to really make good use of your hardware you need to understand your hardware and code accordingly. I doubt you can achieve great performance on a language that focuses entirely on mathematical representations without considering the hardware. So yeah... you end up with a beautiful mathematical expr…

You can do both.. But it is hard.. https://www.youtube.com/watch?v=zt0OQb1DBko

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#238
post #222

Earlier quoted context omitted.

It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then…

Why not just explain it in less detail? Public so that java can see it. Static so it just lives here, no need to create objects. And void is that no value is returned, we will just print our results. Java calls it as program runs, thus main(). Btw, object is something you can create and call methods – functions of that object. Static may be hard to understand, but it is something you just can do. You can say(hi) and…

You can't teach that without touching all the concepts you mention. These would be almost all later parts of the course.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#239

Earlier quoted context omitted.

It triggers me to no end when I watch an introductory course, for people with no previous exposure to any programming language, and the teacher starts with "public static void main()" In order to understand it, you need to have a good grasp of classes, static methods, access controls. This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. Then…

> This is usually followed up by a request to ignore the entire line, which is one of the worst habits you can have as a developer. It is usually a request to ignore it for now, because "we will get into each part latter". I fail to understand what is so bad about it. It's just not practical to provide all the theoretical foundations upfront, and postpone practice to the second semester. Up to this day, I still think…

I think of it a bit like how physics start with that frictionless vacuum, or skip relativistic stuff for later.

Re: If You're Not Writing a Program, Don't Use a Programming Language [video]

#240

As a side note: this presentation has a lot of wasted space in the video, and no offense to the speaker but I'd rather have a better view of his slides than his face. I can't even read some of the algorithms put on the screen!

I agree, the slides and speaker views should have been flipped.
Post reply on HN