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

121–130 of 288 posts

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

#121

Post by romaniv »

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…

>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".

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

#122

Post by cicero »

Retric wrote: post #106
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…

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.

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 advantage of the discipline of using local variables whenever possible because I had experienced the difficulty of tracking down where in the whole program a global variable might be changed.

It could be argued that local variables are just syntactic sugar over a global memory space, but no one credibly argues today that we should therefore only use global variables. Local variables make it easier to reason about the behavior of a program, and it appears to me that functional programming takes that idea even further.

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

#123

Post by quickthrower2 »

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 OK for them to postpone functional to later years on even the PhD.

You mention grief with OO - but I think a lot of it you would get with Functional too and it has more to do with the incentives and people structures in organisations that produce code. Usually praise goes to those who get a 8 hour Jira ticket done in 4, or a 5 week task done in 4 weeks etc, and from the users point of view 'it works'. The structure of the code is not discovered until later.

Code reviewers are working at the deckchairs level, they are unable to change the Titanic's direction, and again both parties in a code review have incentive to do it as quick as possible (while not looking like they obviously brushed over it), so it become mostly a potential bug hunting and syntactic cleanup exercise.

It's almost a running joke that refactoring rarely gets done, and if it does it is trivial, and usually required some stealth from a developer or manager to create cover to do the refactor.

The only hope we have is to work somewhere where there is a good understanding of code quality from top to bottom in the org, or at least when you cross the technical/non-technical boundary there is a high degree of trust to let the tech people do the right thing, and not KPI them into submission.

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

#124

Post by tormeh »

Nursie wrote: post #65
dmreedy wrote: 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…

>the attitude that rigor and formal technique is worth the additional effort Commercially speaking - it's usually not.

Totes agree. Also, customers are humans. They don't want to be handed a perfect product. They want to be involved in the process. Make dumb decisions. Complain. Receive bugfixes. Repeat.

I don't know. Maybe I'm jaded, but I think in B2B, good software is not even desired. In B2C, sure, as Apple proves, but not in B2B.

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

#125

Post by Nursie »

im_down_w_otp wrote: post #113
Nursie wrote: post #83

Earlier quoted context omitted.

To me it speaks of Software being "good enough" far more easily than it can be perfect. > To me it seems like an incentive problem Why is it a problem if a buyer gets something that works well enough for a lot less time/money put in? Further to that - specifications and requirements are often imperfect, poorly pinned down, ever-changing. Software creation out in the commercial world has shifted working patterns to tr…

I'm not sure I follow. The challenge with this formulation of "ever-changing" is that it assumes that things like Agile methods are somehow creating the capacity to iterate toward something of value with intention and ambition in such a way that you'll achieve whatever it is that you're trying to achieve. However, what happens is that the lack of rigor in software development today seems to cause the lineage of devel…

> The challenge with this formulation of "ever-changing" is that it assumes that things like Agile methods are somehow creating the capacity to iterate toward something of value

If you're doing it reasonably well, they produce small chunks of something valuable every iteration.

> Creating a bunch of brittle technology and technical debt

Who's creating brittle software or technical debt? Things can be well designed and well written, well structured and well tested without going as far as formal proof, which in most commercial situations is going to be masses of overhead and quickly not applicable to the ever-shifting problem domain.

> It's a really weird thing to me that as an entire ecosystem and community we've decided that the most valuable way to approach software is to declare that it's impossible to ever "finish" it.

You seriously need to get out into the commercial world more. Or perhaps into the smaller, faster moving commercial world (I'm not sure where you are now).

> If I have a series of high-assurance layers to build upon that I know I can trust,

Then the underlying assumptions are likely to change, rendering your layers an expensive boondoggle.

> I've been in situations where Product Managers and Engineers spent months off and on arguing over some proposed solution

Then you have bigger problems than formal proof.

I'm generally looking at things which are designed and delivered within a number of months - anything that takes months to argue over has entirely missed the boat as far as I'm concerned.

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

#126

Post by pron »

cwyers wrote: post #117
pron wrote: post #102

Earlier quoted context omitted.

It most certainly isn't. It is generally impossible to interpret/compile a TLA+ algorithm efficiently (i.e. as a program that runs with similar complexity to the algorithm) because of the inherent nondeterminism in TLA+. OTOH, it is precisely this nondeterminism that allows you to use TLA+ to describe any algorithm/system at any level of detail. In fact, you can show that a language with similar descriptive power to…

Since when is it a requirement that a programming language be efficient? My larger point is that he seems to be using "programming language" as a shorthand for an imperative, typed programming language. A lot of what he says doesn't seem to apply very well to SQL or Prolog or Lisp, for instance. (I say this having only skimmed the slides, I don't have two hours for this right now.) I won't say that it's a straw man,…

> Since when is it a requirement that a programming language be efficient?

It is (generally) a requirement that if you're writing a linear time algorithm, then the compiled/interpreted language will be executed in linear time. This is not the case for TLA+. You can describe linear time algorithms in a way that can only be compiled into, say, an exponential-time program, and possibly even not at all (i.e., extracting an implementation is undecidable).

I wrote about this at some length here: https://pron.github.io/posts/tlaplus_part3

> My larger point is that he seems to be using "programming language" as a shorthand for an imperative, typed programming language

He means a language with the property I mentioned above. It is somewhat true that Prolog has a tiny portion of the expressive power that comes from a truly nondeterministic language such as TLA+, but it still falls under "programming language." If you want to get technical, a language such as Prolog can let you program with some limited use of quantifiers. In TLA+, you can specify using unlimited use of quantifiers ranging over infinite and even uncountable domains.

In TLA+ you can describe the property "decides halting in linear time," and then show that a specific implementation can do so in some special cases for example. No programming language can do that (i.e. describe non-computable "algorithms") but it is essential for specification languages.

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

#127

Post by StreamBright »

Retric wrote: post #106
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…

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 me.

I have struggled with the concepts of Java for a long time, especially with the many keywords that I cannot relate to, private, final, static, void while I understood majority of Clojure at the first glance. I could not write Java without an IDE but more than happy to develop Clojure with VI. It appears to me that we overcomplicate things for no good reason and underestimate the power of simplicity.

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

#128

Post by theoh »

Joe-Z wrote: post #107
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…

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?

The phrase probably refers to Unix pipes: https://wiki.tuhs.org/doku.php?id=features:pipes

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

#129

Post by Nursie »

tormeh wrote: post #124
Nursie wrote: post #65

Earlier quoted context omitted.

>the attitude that rigor and formal technique is worth the additional effort Commercially speaking - it's usually not.

Totes agree. Also, customers are humans. They don't want to be handed a perfect product. They want to be involved in the process. Make dumb decisions. Complain. Receive bugfixes. Repeat. I don't know. Maybe I'm jaded, but I think in B2B, good software is not even desired. In B2C, sure, as Apple proves, but not in B2B.

> good software is not even desired.

You can make good software without formal proofs. It just may not be proven to be perfect.

> They want to be involved in the process. Make dumb decisions.

This I agree with though, sure. They do make dumb decisions, and they push ahead anyway, even when told. Later they change their minds, we change the software. It's the grand circle of life or something.

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

#130

Post by im_down_w_otp »

dchichkov wrote: post #115
im_down_w_otp wrote: post #71

Earlier quoted context omitted.

Absolutely agree. I work in the autonomous vehicle space, specifically in creating high-assurance resilient systems, and I've had more arguments that I care to count which went something like the following: Them, "All that extra effort sounds great, but we don't have the time to do that. It will explode the really tight build, test, debug cycle we have now. Suddenly every cycle will be 100x as long." Me, "First of al…

The problem is, most of the people who you are working with, only have 0-2 years of experience in the technology that they are using (use of research / deep learning to build products). Look at their resumes. They'd be either recent PhD grads, who haven't built a single product in their life. Or traditional engineers who had just joined the field of building products with an approach that is very different from one t…

That's an institutional problem though.

Yes, it's true that most companies hire way more people, way too quickly than is probably prudent for a problem domain (especially one that is still such an open-ended science project like AVs), and that as a result barely anybody has any idea what they're doing measured against what's being expected of them, but that's a wound that is entirely self-inflicted. It's not a natural law that one needs to suddenly staff up dozens or hundreds of really expensive people ahead of any real capacity to train or assimilate them, but it does happen with depressing regularity. If anything, I'd say this is probably the biggest problem I see in the ecosystem that you and I are in.

The team I work with is small. Everyone has several (5-15) years of experience consuming research, turning it into practical solutions, and in some cases even having created a novel practical application that was later supported by adjacent research.

It's not easy to construct a team of half-dozen to a dozen prolific programmers w/ a bent toward the academic, but an innate sensibility for remaining pragmatic and applicable. But, it's also not impossible to do so either. This is inline with my incentives comments elsewhere. I think the incentives are broken at too many layers to be able to be fastidious and intentional about how we solve problems. Say you get an "empire builder" into the leadership structure... you're doomed. The whole point of everything becomes about having as big of a "rockstar" team as possible, not about trying to solve a problem. Unless the problem one is trying to solve is how to quickly become the SVP of an extremely expensive and probably fairly unproductive team of increasingly disaffected previously very effective people.

Post reply on HN