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…
If You're Not Writing a Program, Don't Use a Programming Language [video]
231–240 of 288 posts
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#232Earlier 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…
>"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]
#233Earlier 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…
>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]
#234Math 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]
#235Don'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…
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]
#236Earlier 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…
How can we bring state forward during development?
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#237I'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…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#238Earlier 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…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#239Earlier 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…
Re: If You're Not Writing a Program, Don't Use a Programming Language [video]
#240As 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!