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

Programming breakthroughs we need

yoyo-code.com

Post reply on HN
Print view View original

131–140 of 511 posts

Re: Programming breakthroughs we need

#131

Post by touisteur »

yaccz wrote: post #98

> the text is just a tool to manipulate some abstract model of the program. yup. > When you think about it this way, it becomes clear that using a textual source code is really inefficient way to manipulate this model. Hard nope. All the attempts at different approach were a failure so far. Text so far is the best thing we have because text can be analyzed formally and computed with by computers. This is the result o…

To add to this, I think text still needs to be the canonical representation of programs. But we're still ways away with tools to express ways we want to modify, generate code. I think the late Pieter Hintjens had the right of it: we should generate code more often (I know it's polemic here). Not behind some magic curtains like the overly complex (for me) and difficult-to-inspect c++ templates but actual code generators.

One example: recordflux [0] generates, from a high-level dsl, SPARK code that can be proved to be Absent of Run-Time Error. It has a model checker for high-level constraints but lays out serialisation/deserialisation code to access fields. They've been recently working protocol/session-level modeling and it's getting very interesting.

I have a similar tool that I use to generate AORTE serdes code, but once you have that, you can go on to generate fuzzers, proxies to other techs.

We're probably also missing a way to target interesting intermediate representations of programs (either Why3 VCs, cbmc GOTO, but maybe also to lean 4 or whatever temporal logic tool of the day, or other automated/assisted proof or generation environments).

Writing those is a huge undertaking every time, and a lot of duplicated potentially buggy effort. I look at the amazing work that's been done (and still being done) to bring up libadalang, a parsing and high level semantic query tool that changed my day-to-day coding paradigm. One of the missing pieces of the puzzle is to me the 'generic parser and semantic specification' that would generate an interpretor and all those proxies for you.

[0] https://blog.adacore.com/recordflux-from-message-specificati...

Re: Programming breakthroughs we need

#132

Post by ChrisMarshallNY »

I liked the section on testing[0].

I tend to write far more testing code, than the CuT, itself. Many of my various widgets have test harnesses that are, in and of themselves, full-fat, App Store-ready apps.

I find test harnesses are generally better (for me), than unit tests[1].

I was just thinking about this, this morning.

I'm what people refer to as a "crusty oldtimer." I wrote my first program (Machine Code) in 1983, so I've seen some changes in the landscape.

These days, the general posture of many shops seems to be "Our programmers suck, and can't be trusted to write code güt." Sadly, this is not necessarily an inaccurate stance.

It tends to result in highly defensive IT infrastructure and process, though, with heavy reliance on languages and strict, rote methodologies.

I used to write a lot of code in C++. Nowadays, people seem to freak out, at the thought of writing in C++. It's entirely possible to write safe, performant code, in C++, but it isn't enforced by the language. The same for PHP, which I've used a lot.

It's also quite possible for bad programmers to write truly nightmarish code in both languages. I know of which I speak, having written quite a bit of said "nightmarish" code. That's one of the reasons I write fairly good code, these days.

The conventional wisdom seems to be that we need to rely on the tools (languages, IDEs, VCS, CI/D, etc.), to assure good code.

That's fine, but it seems to stem from an unwillingness to invest in the most expensive component in a cubicle; the software engineer.

This is a long, tiresome discussion, with no one willing to change their minds, so I'm not going to follow up on it.

I did notice that this posture seemed to start in the mid-1990s. Before that, companies put ridiculous amounts of trust and investment in us.

[0] https://yoyo-code.com/programming-breakthroughs-we-need/#tes...

[1] https://littlegreenviper.com/miscellany/testing-harness-vs-u...

Re: Programming breakthroughs we need

#133

Post by heurisko »

jaredcwhite wrote: post #115
heurisko wrote: post #105

Earlier quoted context omitted.

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

> When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

If you don't mean just HTML but some server side processing, yes, I would. This is still PHP's bread and butter and being able to bind a form to static types is really convenient.

Re: Programming breakthroughs we need

#134

Post by akersten »

csours wrote: post #100
probablypower wrote: post #93

For me it is the separation of business logic and data from the programming implementation. Often the workflow in automating a work process is: - Worker has intuition on how things work - Specialist starts automating and running into exceptions, walls - Worker explains exceptions as they're discovered - Specialist adds spaghetti to the 'clean' business logic model they started with - This keeps going until the end re…

Wow. I would say the complete opposite. Why are you writing a program for work unless you are helping to solve a problem? The implementation only exists to work with business logic and data. Excel is an implementation that does not care about business logic and data. Anyone can add their own business logic and data.

That most of the business world lives and breathes Excel is a testament to OP's point. Companies can cram whatever garbage logic they like into a spreadsheet and no one has to call a developer Microsoft because their pivot table isn't doing The Business Thing that they expect - the end users simply have the power to understand and fix the problem themselves.

Re: Programming breakthroughs we need

#135

Post by joshlemer »

29athrowaway wrote: post #36

My 2 cents: There are thousands of projects trapped into formatting hell because nobody wants to touch git history. We need a standard to fix formatting programming without messing up history.

Some code formatters such as Spotless (https://github.com/diffplug/spotless/tree/main/plugin-gradle...) allow you to format code only in files that have changes against some designated branch such as `master`. So, you check out your feature branch, make changes, do some commits, and run spotless. Only the files which have some changes between your workspace and the master branch will be formatted. This allows you to gradually format the project as and when files would be changed anyways.

Re: Programming breakthroughs we need

#136

Post by davewritescode »

jaredcwhite wrote: post #99

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

I love Ruby, I'm not a dyed in the wool Rubyist but I've been involved with some fairly large projects that were written in Ruby and in my experience writing Ruby code can feel somewhat magical and empowering because of how fast you can get ideas down. As much as I love Ruby the meta-programming and the type system can make refactoring a complete nightmare and as projects grow larger they tend to become a really big mess.

Re: Programming breakthroughs we need

#137

Post by zasdffaa »

jaredcwhite wrote: post #99

As a dyed-in-the-wool Rubyist, I consider Ruby the pinnacle of high-level, abstracted, expressive programming for the contexts I care about (small web applications largely written by solo devs). What's sad to me is that the modern follow-up to Ruby seemingly doesn't exist. Every hot "language du jour" which has come after Ruby has gone BACKWARDS. Lower-level, more systems programming oriented. Maybe even compiled. St…

> What I actually want is a ... and then letting the computer determine the most efficient way to develop those code paths and execute them

Give us something actionable and not handwavy dreaming and you might get it.

Re: Programming breakthroughs we need

#138

Post by panstromek »

Supermancho wrote: post #86
smallstepforman wrote: post #25

I’ve been programming for over 30 years, and never been as productive as before. Need to load and decode a jpeg/png, I grab stb_image.h. Need to decode an ogg file, libogg. Need to decompress, libz. Need to decode video, libavformat. Need physics, libbullet. Need truetype fonts, freetype. Need a GUI, Qt. Need SSL, libssl. My day becomes selecting libraries, integrating them, and testing integration. My business code…

> Writing tests is time-consuming, usually doesn't scale, and it easily creates tight coupling with implementations After thousands of years, humans still use double accounting in finance. This is because it's effective. Unsurprisingly, it's tightly coupled to the original transaction recording. The constant assertion that tight coupling is bad, because it creates more work which can be error prone. This is a fundame…

I think "double accounting" is a good analogy, and if you look at it that way, some tests that look like the same thing written twice in a different way start to make more sense.

The problem is just with effectivity - it'd be fine if the time spent on test would be the same as time on code, but very often the effort on test is much bigger while not even covering all important cases. I think we need to look for methods to get a good case coverage without spending majority of our time writing tests.

Re: Programming breakthroughs we need

#140

Post by choeger »

jaredcwhite wrote: post #115
heurisko wrote: post #105

Earlier quoted context omitted.

> Static typing everywhere. I think the industry has generally recognised that static typing makes more reliable software. I started with PHP and have seen its type system evolve. Similarly Typescript. I since moved to other staticly typed languages. I wouldn't want to go back.

Depends on the context. When you're programming a transactional banking system? Heck yeah I want static types. When you're programming a form on a web page? It's way-ay-ay more effort for dubious gains, with new downsides added into the mix.

> It's way-ay-ay more effort

Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming.

Generally speaking, if doing something with a proof of type-safety feels complex, you probably ignored many corner cases before.

Post reply on HN