Live data from Hacker News

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

youtube.com

211–220 of 288 posts

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

#211
post #10

I believe these are the kinds of ideas that might actually create a genuine engineering culture in software development. Until we start applying this kind of rigor to our work, I don't believe the title of "Software Engineer" is justified. It doesn't have to be TLA+; it doesn't have to be any particular tool or technology or pattern or whatever. But the attitude that rigor and formal technique is worth the additional…

I disagree that engineering is the best approach to writing software. I think this is the fundamental difference between people who prefer static vs dynamic typing. People who prefer static typing are more likely to say that one solution is more "correct" than the other, whereas dynamic typing allows more flexibility. I see writing software to be similar to writing music. Music has rules and structure, but leaves roo…

> Static typing imposes limitations (kind of like government),

where to begin

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

#212

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…

Could you elaborate on how you came to be programming in C/C++ for 7 or 8 years before encountering a spreadsheet? That seems an unusual path even back in the 90s.

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

#213
post #162

Earlier quoted context omitted.

A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway. And one of them is axioms no-one ever communicates . I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less ex…

Yeah, interestingly, I have this impression that Python is a modern-day Fortran. (Largely for the reasons you describe in the third category of programmers.)

At least among my colleagues (process engineering) the language is basically an afterthought. Your slide rule analogy is right on.

For a lot of the people I work with code is just a way of representing mathematics. So you end up with "Fortran written in every language"

Here is a snippet of code (this is written in C but I guarantee most of my colleagues would write this the same regardless of it it were fortran, python, Matlab what ever).

           for (i=m1;i 
Here's some SQL

SELECT t2.Line, t2.Slope, t1.X, t1.Y, t1.Y - (t2.Slope * t1.X) as Intercept /* B = Y -Mx */

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

#214
post #162

Earlier quoted context omitted.

A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway. And one of them is axioms no-one ever communicates . I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less ex…

So where do Smalltalkers and Lispers go?

Outside in the car park playing hackey sack

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

#215
post #162
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.

A ton of problems in software engineering, I am convinced (and isn't wild generalization one of the marks of our field! I at least want to own my own hypocrisy here) are communication problems. Nearly all the interesting ones, anyway. And one of them is axioms no-one ever communicates . I've worked with programmers with at least three markedly different axiomatic bases, for want of some less pretentious – and less ex…

I like that categorization. One semester during college I was taking both a computer architecture class, and an automata/theory of computation class--I still remember when I realized that there were 2 fundamentally different ways of approaching computing. Studying the history of computing, you'll also come to a similar realization that there are 2 fundamental approaches.

Personally, I've always loved both paradigms, and I've never been able to decide which one I prefer. I tend to move between the 2 depending on which one works better for the task at hand.

That realization (along with the fundamentals required to understand both paradigms) was one of the most useful things I got out of my degree.

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

#216

I don't know who the target audience was, but I found the lecture very confusing and the message really badly passed (he keeps talking what is already written in the slides, etc.). I had to play it at 1.6x the regular speed so I could move on with it. Regarding the topic, I think there are multiple ways of expressing ideas, where math happens to be just one of them. For instance, for the Greatest Common Divisor examp…

I think he was trying to show that the TLA+ approach led to easier proofs of the base case and inductive case. I don't think he's arguing that your gcd program is bad. That's what I'd use. But TLA+ might be a good tool to break out when you need to have a solid proof that the code you wrote will always end up getting you the right answer. We probably don't need it for side projects, but it's nice to know that AWS has some proofs around that the services I use there can't end up in an inconsistent state as a result of any coding logic.

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

#217
post #204

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…

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.

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

#218

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 was never very good at that--ignoring something until later when it's staring right at you.

I prefer teaching programming with a language that minimizes the boilerplate required to get started.

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

#219

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…

> 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

Most CS curricula have a course where you spend time programming in a variety of different programming languages, in different paradigms.

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

#220
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…

Purely functional languages come with the promise that a sufficiently advanced compiler will see through all that monadic functional cruft and run your code as well or even better than it would if written in an imperative language. As we don’t yet have such an advanced compiler, impure hacks like `par` start seeping through the cracks.

What do you mean impure hacks like `par`? It's a parallelism primitive. You mean `seq`? In either case it's not impure. It's just a primitive that can't be expressed in the language itself. It's still referentially transparent (which is what people mean by pure).
Post reply on HN