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

391–400 of 511 posts

Re: Programming breakthroughs we need

#391

Post by sleepybrett »

barnabee wrote: post #307
ziddoap wrote: post #215

Earlier quoted context omitted.

> excel has a learning curve like anything else, Agreed. > But excel proficiency acquisition is very similar to a programming proficiency acquisition Strong disagree. Maybe if you only consider those extreme cases you referenced (ray-tracing, heavy VBA, etc.), sure. But in general? No shot. Excel gives immediate feedback with a visual interface. There's no need to learn about variables or syntax or memory or compilin…

The amazing thing about Excel is that many (most?) people start using it without EVEN knowing how to make a simple formula. They literally start using it as a way to lay out tables (usually of data). Then they make graphs. And add more tables. And learn how to use it like a basic pocket calculator (half of the formula I see that should be sums are actually =B21+B22+B23+B24+B25…) Then comes SUM. Then VLOOOKUP. Perhaps…

Honestly I tried to do some simple shit in excel today for the first time in years and holy shit, who thought this ribbon interface was a good idea. I'm going back to apple's numbers.

Re: Programming breakthroughs we need

#392

Post by Jensson »

crummy wrote: post #390
thaumasiotes wrote: post #383

Earlier quoted context omitted.

That's hard to argue with, though Java isn't known for convenient UI development either.

what languages are known for convenient UI development?

The sum language of HTML+JS+CSS, or in other words html files. I haven't seen a better way to write UI in text files, other UI frameworks relies a lot on building the UI in some special editor or aren't easy to use.

Re: Programming breakthroughs we need

#393

Post by thrown_22 »

the_duke wrote: post #354
SKILNER wrote: post #34

Great post - the one word missing, "maintenance." Most programming work is done maintaining/enhancing existing code. The greenfield work is a piece of cake by comparison. You want to do the hard stuff? Maintain existing code you're not familiar with. The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky. There's a little branch of computer science called Program Comprehension…

I see this largely as a language failure. Alot of popular languages make it really easy to write code, but hard to maintain it . It's one of the reasons I like Rust so much,even for relatively high level code. It has one of the srictest type systems and std/library ecosystems of any language in existence, which tends to make code very robust and easy to refactor. I often wish for a language that has a similarly stric…

>Alot of popular languages make it really easy to write code, but hard to maintain it .

The language you're writing in has next to no meaningful impact on long term maintenance. When you're trying to do software archeology on why a function even exists the types it has will not help you figure out it's there because between 1996 and 2002 there was a tax rebate on capex for rocket development.

You need human understandable documentation, not fancy language features. This is no where near as sexy so no one does documentation and we're in the middle of a digital dark age.

Re: Programming breakthroughs we need

#394

Post by fullstackchris »

riskable wrote: post #167
swatcoder wrote: post #71

Earlier quoted context omitted.

Nothing so dramatic. The alternative is judicious inclusion of dependencies rooted in thoughtful, experienced engineering. Robust, comprehensive libraries from reliable vendors can provide a lot of value and are slow to rot. These can be anticipated and added early so that they’re made good use of and can become the first tool to reach for before adding other dependencies. Think React, lodash, QT, boost, etc. Meanwhi…

> Robust, comprehensive libraries from reliable vendors Hah! In all my years the biggest, most difficult vulnerabilities/problems to remediate all came from vendor-made (90% of the time closed source) software. With the free, open source stuff the problems are usually very minor but even if they're BIG we'll pretty much always get fixes and deploy them faster than if we had to wait on a vendor. The more popular the O…

What language code is written in has little to do with how "flexible" it is. Or what did you mean? Refactorable? Readable? I don't immediately see what the choice of Python specifically has over other languages.

Re: Programming breakthroughs we need

#395

Post by xupybd »

I feel like Scott Wlaschin has helped me overcome some of these problems with his book (https://www.bookdepository.com/Domain-Modeling-Made-Function...)

It's not perfect but defining your types so it's hard to get into error states is amazing. https://fsharpforfunandprofit.com/posts/designing-with-types... It's like having database constraints but at compile time.

Re: Programming breakthroughs we need

#396

Post by chii »

thaumasiotes wrote: post #383
chii wrote: post #374

Earlier quoted context omitted.

it's a bit exaggerated, but it's true that the standard built-ins for javascript is poor compared to something like java.

That's hard to argue with, though Java isn't known for convenient UI development either.

well it depends on what you mean by convenient - java's got a UI toolkit that works out of the box for all supported environments (awt), and ontop of that is built a fair number of UI frameworks like swing (which is also part of the java standard library).

Re: Programming breakthroughs we need

#397

Post by indymike »

Programming has always been making really detailed instructions that tell machine what to do. The article could have been written in 1989, 1995, or 2005 and really been materially the same. Glue code, boilerplate, tests, frameworks, languages, and maintaining existing code all things that developers complain about. All things waiting for the next magical solution...

We largely build software the same way with the same tools (I'm looking at an Emacs window). One line at a time (or one boilerplate paste at a time). It's been decades since I sat down with Turbo C and discovered the ID, and decades since I drew my first UI on a NeXT Cube. Decades since Java, Python and C#. We've never found a way to program at a higher level - we're still stuck processing strings, parsing text, formatting text... all these little details that make it really hard to work at a higher level of abstraction. And all little details where each developer does it just enough differently that we can't be sure what our code really does...

I guess that is how job security works.

Re: Programming breakthroughs we need

#398

Post by bmitc »

CodeMage wrote: post #357
vlunkr wrote: post #305

Earlier quoted context omitted.

I've also wondered if it's time to back off on agile a bit. Or at least "agile" as it is implemented generally, which means we get to make up new requirements every two weeks. In my experience, the hardest maintenance problems occur because we're trying to re-shape code into something that the developers never knew would be coming down the line. Spending lots more time up-front deciding requirements would go a long w…

Maybe I'm just an old curmudgeon, but it seems to me there's way too much emphasis on speed of development in general. Time to market seems to be more important than quality, robustness, security, performance, or any other concern. Another thing that rubs me wrong is the recurring notion that we need to get rid of the text as a representation of code. I've yet to meet a mathematician who wants to get completely rid o…

> Another thing that rubs me wrong is the recurring notion that we need to get rid of the text as a representation of code. I've yet to meet a mathematician who wants to get completely rid of formulas because coming up with a proof is slow and cumbersome.

I see what you're saying, if I understand correctly, in terms of the hype around "low or no code" environments, if that's what you mean. However, I do disagree with the notion of equating code with text. It seems myopic in the same fashion of equating tape or punch cards with code.

Also, I think the mathematics example isn't quite apt. Mathematicians are very willing to use visual representations to both illustrate and prove ideas. The way mathematicians work is actually a great example of moving between visual and symbolic representations and also prose.

In many significant ways, text is a highly limiting form of expression. In my opinion, we have nearly tapped out the available expression that can come from purely text-based programming languages. One example of this is the limitations of the innovations in syntax. There's been basically no significant innovation in this area aside from small iterative improvements, and I think that's a fundamental limit we've hit. I feel the future of programming is likely to hinge on a highly hybrid environment. In some sense, Smalltalk and its ilk, Emacs and Common Lisp, TouchDesigner, LabVIEW, and vvvv are precursors for what could come.

Re: Programming breakthroughs we need

#399

Post by fullstackchris »

js8 wrote: post #5

I would suggest to author to look at functional languages, like Haskell. These are based on principles of function composition and referential transparency. The move from testing to static analysis is happening there, in the expressiveness of the type system, and its inferences. Functional languages are on the forefront of experimentation with new type systems.

> The move from testing to static analysis

Are you claiming that static analysis of code can replace the concept of writing tests completely? If so, I'm very skeptical.

Re: Programming breakthroughs we need

#400

Post by nextos »

troutwine wrote: post #358
fleddr wrote: post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

At least from the systems programming perspective I think productivity gains have been significant. Valgrind had _just_ appeared as I was doing my undergrad and it allowed me to focus on the high-level math of data structures -- as an example -- compared to my non-Valgrind using classmates that were struggling with memory bugs (which, of course, I did too, but to a less degree). C++ has noticeably improved since then…

> Ada has made real strides back from the dead, especially if you can stick to SPARK Ada. We're even seeing more formal verification of complex bits of software in systems-land, something that seemed basically impossible when I first read about Coq twenty something years ago.

I really agree with this. The situation is a bit crazy. Since formal proofs are hard, the alternative taken is giving no guarantees at all. That's bad. Static analyzers can get really far. Contracts, even just at runtime are really useful. I don't want a piece of code to run if the precondition is not met, and I don't want it to return or have side effects if the postcondition is not met. This would rule out a massive class of errors. Of course, bonus points if you can do it at compile time.

Ada SPARK, Infer [1] and Dafny [2] show that rigorous engineering is possible and practical. Actually, Facebook (Meta now) argues Infer let's them move faster.

I think the problem is political and economical. It's hard to monetize this first. I wish someone like Apple took the plunge and rebuilt a simpler version of their stack using formal verification. It's the kind of thing only a large corporation or a government can do because it might take half a decade to take off. Once it takes off its unstoppable. Who would not like to buy e.g. a phone where most bugs and security breaches are impossible by construction? Verification also has a nice side effect. Change for the sake of change and featuritis are pretty incompatible with it.

[1] https://fbinfer.com

[2] https://github.com/dafny-lang/dafny

Post reply on HN