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

441–450 of 511 posts

Re: Programming breakthroughs we need

#441

Post by samsquire »

bmitc wrote: post #332
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…

It's interesting to me that people are so into Agile when it simply doesn't work all by itself. How many books, conferences, certifications, practitioners, evangelists, etc. does it take to make a paradigm, supposedly the paradigm, of working actually work? Every company I have worked for that used Agile basically had broken processes and were not productive. The one job where we did not explicitly use Agile was actu…

I think engineering effectiveness comes down to a people and communication problem.

Writing software well is difficult by itself and people are all different in understanding, experience and skill level. Throwing a group of people together and trying to build something that works for every scenario is a miracle given the complexity of software and the complexity of interpersonal relationships and organisations (see Conway's law). I'm impressed by every multiplatform language or tool or software. It's a lot of work!

If everybody did things the same way i.e the agile way and if agile was proven to work and everyone followed it the way it was intended and designed, then maybe we could all be interoperable and easily work together and produce projects that don't fail. That's the fantasy.

To be fair I've been 6 years worth of agile projects and I was never on a project that failed.

Re: Programming breakthroughs we need

#442

Post by KronisLV »

_gabe_ wrote: post #385
CodeMage wrote: post #357

Earlier quoted context omitted.

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 completely agree with this notion. However, I feel like we're sorely missing out on some form of visual exploration. I feel like the majority of my time is spent trying to understand the flow of execution of a program I'm trying to maintain that was written by other teams that are long gone. I…

Sourcetrail actually tried to do that for a select few languages https://github.com/CoatiSoftware/Sourcetrail

Sadly, they retired the entire project a while back.

Re: Programming breakthroughs we need

#443

Post by samsquire »

galdosdi wrote: post #247
dlojudice wrote: post #159

Earlier quoted context omitted.

the problem is that a large amount of code produced is to support the accidental complexity of the software (let's call it infrastructure code) while the value generated by it comes from its essential complexity, that is, the application domain, as cited by the article . while Domain Driven Design and Clean Architecture are a first step in the right direction, languages and frameworks are still limited in supporting…

I think, as OP alludes, ultimately explorability is the heart of the problem that stops people from writing code this way. If you don't care about other people being able to read and explore your code without a lot of preperation, you can go full hog creating layers of DSLs and metaprogramming, and with enough dedication you can end up with all your real domain level business rules in one place separate from the "inf…

I agree with you!

I find other people's code difficult to follow due to all the abstractions that I wouldn't have inserted.

When I write Clojure code for example, the code just works. I somewhat understand the code I write.

But when I read other people's Clojure, I find it difficult to understand. I think it's my maturity in understanding Clojure, the mental model isn't there yet. Which is funny because I've been on two projects where we used Clojure.

I don't have the same problem with less metaprogramming languages such as C, Java or Python.

Re: Programming breakthroughs we need

#444

Post by samsquire »

commandlinefan wrote: post #211
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…

> The problems around maintaining unfamiliar code are huge, largely unsolved, expensive and risky Not to mention massively underestimated and unappreciated by non-programmers.

A software engineer, coder and developer's responsibility is to manage technical complexity and solve technical, data or business problems.

I'm not sure if we are respected for this capability. Do people want to pay for what they do not understand why it is so hard?

Re: Programming breakthroughs we need

#445

Post by hutzlibu »

magic_hamster wrote: post #440
bluejellybean wrote: post #403

Earlier quoted context omitted.

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programmin…

In game engines, and especially in UE where things like Blueprints exist, the low level stuff is just conveniently hidden or abstracted away. But the long textual code that makes the button work, eventually exists somewhere in there. At least when you write it yourself, you know who to blame (and probably where to look) when it doesn't work.

"the low level stuff is just conveniently hidden or abstracted away. "

Yes. This this is exactly what I want.

When I write an engine or framework, I will deal with low level stuff. But for basic tasks, I don't want to. But I have to, even where it would not be necessary.

"But the long textual code that makes the button work, eventually exists somewhere in there."

Also there exists even longer textual or even binary code that makes the code for the button work, etc. etc., but I still do not want to deal with it on a daily base. When I make an button, it should be as simple as possible.

Where is it positioned. How is it styled. Where is the onclick method to handle it. Those 3 things I want to do with simple clicks in the IDE.

Everything else is only distracting.

Re: Programming breakthroughs we need

#446

Post by lejoko »

openfuture wrote: post #201
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…

Obligatory "elixir+phoenix is supposed to inherit ruby on rails" remark

Rails + Phoenix dev here who loves both. Elixir is far from having the conciseness of Ruby and Phoenix is super far from having the tooling of Rails (and Rails from having the tooling of Beam and OTP). From my point of view they are two very different beasts, each one being great in its own domain. The similarities are mostly syntactic and superficial.

Re: Programming breakthroughs we need

#447

Post by [deleted] »

ecopoesis wrote: post #284

I would love to see a language that considers tooling a first class problem. Most (all?) languages barely consider complex projects with 100s of dependencies and large multi-step builds. Java shouldn't have to wait for Maven and Gradle to come along, and Python shouldn't be shackled to piss-poor systems like pip. This is something Rails gets very right. Bundler and Rake make Rails one of the nicest development enviro…

[deleted]

Re: Programming breakthroughs we need

#448

Post by pjmlp »

bluejellybean wrote: post #403
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.…

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programmin…

Not wanting to pay for tooling is the major culprit.

One can pay for a CRM like Sitecore, AEM, low code like Outsystems, or enjoy the freedom of manually glueing HTML, JavaScript and JSS.

Re: Programming breakthroughs we need

#449

Post by pjmlp »

eek2121 wrote: post #408
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.…

Ironically, I know everything from ASM to...well many languages, including C, C++, PHP, Python, Ruby, Javascript, etc. The most productive tools I used prior to learning all of that? HyperCard on the Mac, Visual Basic on Windows. Why? Tooling. Even when you had to get down and dirty, it seemed the tooling helped you out in some way. Shoot, I wrote an application back in the 90s in VB6 that still is functional TODAY n…

What angers me on Windows world is how the WinDev team routinely sabotages VB and C# efforts to be back to those productive flow in graphics programming on the platform.

Managed Direct X, XNA, all killed when their advocates gave up fighting for them.

Nowadays they proudly refer to Unity when one complains about missing .NET bindings to DirectX.

Re: Programming breakthroughs we need

#450

Post by panstromek »

feoren wrote: post #257
feoren wrote: post #249

So, so much is misguided about this article. Yet, the opinions expressed are actually quite common, and I think represent some widespread and fundamental misconceptions about software development, so they're worth addressing. Apparently this comment was too long for HN, so I'll address the points individually in child comments to this one.

Look, of course there's lots of unexplored territory in software engineering, and we absolutely should continue to strive for better programming languages and abstractions. And we are! From reading this article, this author is looking in entirely the wrong direction for such improvements. It's not going to be some magic visual model that One thing we should not expect is that new developments will be easy for us to l…

> It's not going to be some magic visual model

I wasn't talking about visual model at all. In fact, the word `visual` doesn't even appear in the article once.

Post reply on HN