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

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

#141

Post by scarface74 » Mon, Sep 24, 2018, 9:05 PM UTC

outworlder wrote: post #137

romaniv wrote: post #121

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…

Why would universities teach Java and C++ anyway? They are either 'boring' from a computer science perspective, or too convoluted for teaching concepts.

Not a fan of Java by any means, but they should teach Java so graduating students can put that on their resume and get a job so they won't live with their parents until they are 35....

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

#142

Post by Koshkin » Mon, Sep 24, 2018, 9:06 PM UTC

AllegedAlec wrote: post #138

Koshkin wrote: post #110

Earlier quoted context omitted.

> Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.

That explains why astronomers are so incredibly enthousiastic about telescopes, and spend immense amounts of time trying to create better ones to overcome the limits of what they can do now.

Sure, everyone is enthusiastic about their tools. Still, it is not telescopes that are the subject of the science of astronomy.

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

#143

Post by klodolph » Mon, Sep 24, 2018, 9:07 PM UTC

Koshkin wrote: post #110

Retric wrote: post #106

Earlier quoted context omitted.

Computers are still imperative, so all functional code is arguably syntactic sugar over that core causing a lot of leaky abstractions to show up all over the place. I think the problem with Object-oriented programming is it's taught to soon. Start with Imperative then Functional then toss object oriented into your senior year.

> Computers are still imperative "Computer Science is no more about computers than astronomy is about telescopes." — (Mis)attributed to Edsger Dijkstra, 1970.

I'm still convinced that (Mis)Quoting Dijkstra Considered Harmful. A Dijkstra quote derails a conversation about CS almost as surely as anything else.

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

#144

Post by zackmorris » Mon, Sep 24, 2018, 9:08 PM UTC

quickthrower2 wrote: post #123

zackmorris wrote: post #92

I wasn't exposed to spreadsheets until a few years into college back around 1996 or 1997 maybe (I had been programming in C/C++ for 7 or 8 years by then). I wasn't taught matrix math until pretty late in the curriculum, I want to say junior or senior year. Also I was lucky to have a semester of Scheme but they were transitioning to teaching Java around the time I graduated (I don't know if they ever switched back). A…

I disagree that they should phase out imperative / OO programming, but from my experience more emphasis on different languages i.e. throw in a ML (as in Meta Language) and a Lisp, and most importantly some information about the trade offs. However it would require a culture shift as a university being a place to get you ready for a career in industry rather than academia. Because you are prepping for academia it is O…

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 it in students.

I'm still in mourning though imagining how far programmers could go if they weren't stuck endlessly debugging imperative code that will never be deterministic or free of side effects. Lots of lost potential there. I'm coming up on 3 decades of experience doing that and it feels like well over 90% of the code I've written was a waste of time. I guess it paid the bills though.

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

#145

Post by outworlder » Mon, Sep 24, 2018, 9:11 PM UTC

pjmlp wrote: post #35

aidenn0 wrote: post #3

I haven't watched the full talk, so let me know if this gets explored by Lamport, but... Here's a thought: PL researchers seem to generally agree that typed languages are superior to untyped languages, yet programmers tend to prefer untyped languages to typed languages, to the point where Java and C++ have the fanciest type systems in common use, with ML being the closest thing to an academic language that gets signi…

Which programmers?! With the exception of JavaScript, I only use dynamic languages for throw away scripts. I had lots of fun with Lisp and Smalltalk, but can't imagine using them with the team sizes I usually work with.

> I had lots of fun with Lisp and Smalltalk, but can't imagine using them with the team sizes I usually work with.

I have an impression that it correlates less with team size, but rather with average member skills.

Well-written and logically organized Lisp code shouldn't be any harder to maintain just because the team size has increased. Rather, Lisp provides too much power (as in, macro system, compiler easily available at runtime, etc). These can be easily abused and wreck a codebase.

I have chosen Golang for most new development in the group I am in, basically because it forces a straightjacket onto people, even down to things like code formatting. I got tired of asking for people to write unit tests for their Python code – the fact that people can get away with throwing Python code with zero tests into production baffles me, it's like taking C code to production without compiling it.

So at least I got a compiler enforcing some level of code correctness and some uniformity in code conventions. And the fact that noone is overriding anything they should not...

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

#146

Post by Jweb_Guru » Mon, Sep 24, 2018, 9:13 PM UTC

nabla9 wrote: post #13

aidenn0 wrote: post #3

I haven't watched the full talk, so let me know if this gets explored by Lamport, but... Here's a thought: PL researchers seem to generally agree that typed languages are superior to untyped languages, yet programmers tend to prefer untyped languages to typed languages, to the point where Java and C++ have the fanciest type systems in common use, with ML being the closest thing to an academic language that gets signi…

There are very few untyped languages. * Distinction between dynamically typed and statistically typed is clear. * Weak versus strong typing has less clear definition. Usually weakly typed means many implicit conversions between data types and representation. Most programmers like the late binding approach. That is easy to do with dynamic typing. Adding static typing or type inference for late binding is more difficul…

> Distinction between dynamically typed and statistically typed is clear.

Not so clear as you might think. For example, it's relatively easy to construct a typed version of the untyped lambda calculus using isorecursive types.

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

#147

Post by nickodell » Mon, Sep 24, 2018, 9:14 PM UTC

drb91 wrote: post #5

aidenn0 wrote: post #3

I haven't watched the full talk, so let me know if this gets explored by Lamport, but... Here's a thought: PL researchers seem to generally agree that typed languages are superior to untyped languages, yet programmers tend to prefer untyped languages to typed languages, to the point where Java and C++ have the fanciest type systems in common use, with ML being the closest thing to an academic language that gets signi…

> programmers tend to prefer untyped (dyanamic?) languages to typed languages I have not found this in practice. I have found that some developers prefer a dynamically typed language for certain situations, like rapid prototyping. However when maintaining code bases, I've found that developers often bemoan the lack of static types to assist in small modifications to code they haven't touched in a while. Personally I…

I agree.

I recently tried to port an ~11k SLOC object-oriented Perl program from GTK2 to GTK3. The lack of types was maddening. I would have some simple goal, like "find the path of $image." I would immediately run into a roadblock: what type is $image? Is it a string? A file handle? A Gnome2::File?

So I trace the variable back. It's a parameter, so look at one of the places that calls it. That callsite uses a global variable. Aha! I go to where it's initialized. It's initially set to undef. Dead end.

I couldn't help but think, "I wish I was programming in Java right now." That was a new low for me.

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

#148

Post by ken » Mon, Sep 24, 2018, 9:16 PM UTC

Retric wrote: post #132

cicero wrote: post #122

Earlier quoted context omitted.

I have heard critiques of functional programming, but not that there is a problem with leaky abstractions. Can you provide an example? Does it invalidate the discipline of trying to use pure functions when possible? I learned to program using BASIC on an Apple II. All of the variables were global, and it wasn't until I got Apple Pascal that I had access to a language that had local variables. I immediately saw the ad…

Program execution time and memory footprint are great examples. Math does not care about these details, but just because two programs are logically equivalent does not mean they will behave identically. I am very pro functional programming, but your mental model needs to be accurate to really dig into the details. As such you really need to understand ASM and procedural code or it will eventually bite you.

That's a curious place to draw the line. As we've seen in the past year, assembly isn't good enough. You need to understand your microcode or it will eventually bite you ... and you don't.

But that's all just nit-picking <<1% cases. When's the last time you saw a functional program whose execution time or memory footprint were unacceptable, and required knowledge of assembly language (or lower) to resolve? I can't say I ever have.

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

#149

Post by fastball » Mon, Sep 24, 2018, 9:18 PM UTC

fastball wrote: post #64

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!

Downvotes? You guys prefer to not be able to see the slides and to instead have a good portion of the video's space taken up by the speaker themselves? Am I alone in this?

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

#150

Post by nabla9 » Mon, Sep 24, 2018, 9:18 PM UTC

Jweb_Guru wrote: post #146

nabla9 wrote: post #13

Earlier quoted context omitted.

There are very few untyped languages. * Distinction between dynamically typed and statistically typed is clear. * Weak versus strong typing has less clear definition. Usually weakly typed means many implicit conversions between data types and representation. Most programmers like the late binding approach. That is easy to do with dynamic typing. Adding static typing or type inference for late binding is more difficul…

> Distinction between dynamically typed and statistically typed is clear. Not so clear as you might think. For example, it's relatively easy to construct a typed version of the untyped lambda calculus using isorecursive types.

That's completely abstract example, not relevant to actual practice.

It's hard for actual programmer make that mistake.