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

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

youtube.com

Post reply on HN
Print view View original

221–230 of 288 posts

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

#221

Post by mcphage »

zackmorris wrote: post #144
quickthrower2 wrote: post #123

Earlier quoted context omitted.

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…

> 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 calculations. Most programming paradigms are about manipulating the calculations, and the state is only visible when the program is running. As long as programming tries to avoid state, it'll be hard for most people to learn.

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

#222

Post by wruza »

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 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 that requires nothing, but you cannot drive() without a car.

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

#223

Post by learc83 »

vmchale wrote: post #217
ezoe wrote: post #204

Earlier quoted context omitted.

Real hardware is imperative. Object-oriented programming was once treated like Functional programming. The languages which did implement OOP as it was originally thought was horribly inefficient. So practical languages took the good idea out of OOP for convenient syntax sugars. Functional Programming will follow the same path. You probably don't like it for it will be ended up impure and just some syntax sugar that l…

> Real hardware is imperative. Wrong. > So practical languages took the good idea out of OOP for convenient syntax sugars. Also wrong, unless by "syntactic sugars" you mean "nontrivial compiler rewrites" > Functional Programming will follow the same path. Doubt it. > You probably don't like it for it will be ended up impure Purity does not constrain efficiency at all.

>Wrong.

At an abstraction level below digital circuits, you are correct. But thankfully the layers on top of that do almost always do a very good job of hiding it.

>Doubt it.

Functional programming is already following the same path. Sure there will non-hybrid languages around if you want to use them, but take a look at the functional constructs that have made their way into almost every procedural language in use today.

Most people have never touched Haskell, but almost everyone has seen a map function.

>Purity does not constrain efficiency at all.

Maybe not inherently, but there's a reason we have to break out and use mutable data structures when we really need performance. For the systems we are working on today purity does impact performance/efficiency.

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

#224

Post by vmchale »

nestorD wrote: post #12
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…

I find that ML (Ocaml and F#) does not get in my way (Haskell being the exception due to the absence of quick and dirty mutability) while dynamic typing (in python) does hinder me when I depend on external libraries.

> Haskell being the exception due to the absence of quick and dirty mutability

I don't think that's "getting in your way" so much as asking you learn pure, immutable data structures. Which is good even aside concerns of laziness.

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

#225

Post by drchickensalad »

steveklabnik wrote: post #179
zackmorris wrote: post #136

Earlier quoted context omitted.

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…

> I haven't fully learned Rust yet but from what I understand, the borrow checker only applies to mutable data This is not correct. The borrow checker applies to references , both mutable and immutable.

I think the intention was that if you have no mut refs, then you have no borrow checker problems.

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

#226

Post by rileymat2 »

about_help wrote: post #46
jkingsbery wrote: post #25

Earlier quoted context omitted.

"It's quite likely that during their lifetime, machine learning will completely change the nature of programming." - Why is this the case? Even if it's true, it hardly seems obviously true.

Because soon you will just ask your computer to build your code after giving it a few parameters. Then you will proof read and sanity check the code and spend more time optimizing and working on the really hard problems.

Right now source control applications don’t even detect simple merge conflicts based on meaning.

For example if I remove a global variable from a source file and another branch adds another reference to it, if it does not occur on the same line git will happily merge the file with no conflict.

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

#227

Post by rixarn »

thrmsforbfast wrote: post #206
rixarn wrote: 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…

> In order to really make good use of your hardware you need to understand your hardware and code accordingly Understanding your hardware is only half the story. To use the hardware effectively, you also need to have mathemaitcal insights into your problem. A rather extreme proof of this fact is bubble_sort.c vs. quick_sort.java. I think it's clear which of those is using the machine more effectively... > I doubt you…

I agree, you need mathematical insight too you can have that and still code as we do now without sacrificing a way to express solutions that consider things such as cache locality. With what he proposes, that’s simply not possible. There’s a very interesting talk by scott meyers about how important cache locallity is to the point where, in practice, for some problems, big oh analysis breaks because of cache misses. So an algorithm that is faster by those standars gets its ass kicked by a “slower” one just because of cache misses.

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

#228

Post by userbinator »

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…

This doesn't really apply to C++, but I know that Sun was pushing very hard for Java in the early 90s, to the point of basically giving away hardware and course material to universities who would teach Java.

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

#229

Post by orangeshark »

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…

>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. That really bugged me when I learned Java at University. I was also unaware how the compiler built the code and ran it, it was all hidden by the IDE. I felt a bit satisfied by my data structures course which had a pretty decent book that explained a bit of this in the first chapter. I then decided to just switch to using vim and Make to build and run my school assignments.

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

#230

Post by jtms »

StreamBright wrote: post #127
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.

And what about humans? You are rarely writing code for computers, but for humans. Many companies optimize code for readability. And there is a reason. Usually multiple people are working on the same code at the same time, or over time at least. It is the compiler's job to translate the code to computers language which can be imperative, I would still prefer the human side functional and declarative. Maybe it is just…

To be fair, almost no one can (or should) write java without an IDE. IntelliJ + ideaVIM has been a great compromise for me as a long long time VIM user. I know I am not responding to your main point (of which I am sympathetic) but I figured I'd throw it out there anyway
Post reply on HN