Live data from Hacker News

Programming breakthroughs we need

yoyo-code.com

461–470 of 511 posts

Re: Programming breakthroughs we need

#461

Earlier quoted context omitted.

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.

I don’t get the ribbon either, I keep it hidden and put everything I want on the quick access toolbar.

Re: Programming breakthroughs we need

#462

This resonates deeply with me (and my research project). 1. Glue code and boilerplate waste Yes, yes and yes! Glue code is the dark matter of software [1] My hypothesis is that the reason we have to write so much glue code, and that it's always sufficiently different is that we don't have the right architectural abstractions. Specifically, our programming languages only support (essentially) procedural abstraction (p…

> The problem is not the text, it's the wrong abstractions that our text expresses.

Yes, I second that - What I really want is to write an SQL statement to transform my code. It's also a textual method, but on different level.

Re: Programming breakthroughs we need

#463

Earlier quoted context omitted.

>And this doesn't require expensive, licensed software, like Delphi 30 years ago. Delphi wasn't expensive for most of it's life, until they got greedy, and lost the market. Lazarus is the modern open source replacement, it's mostly compatible with Delphi, and $1400 cheaper. ;-)

I programmed in Delphi for years and have done some toy things with Lazarus, so I'm painfully aware of the quality and reliability difference. It is quite bizarre how us programmers, who make hundreds of thousands of dollars per year, are unwilling to pay $1,400 that will make us more productive.

Lots of devs are willing to spend on tools but end up in workplaces where they're not allowed to install them, tools don't offer compatible licensing for that scenario, or where the workplace won't purchase a license for them in tandem with their personal copy.

Look at all the copies of IntelliJ (and derivatives) that are sold. I think people are willing when the price point is right and it can get into the workplace. I personally wouldn't spend $1400 unless I could make my life better from it somehow, and that would mean it making me significantly better at earning money.

Re: Programming breakthroughs we need

#464
post #41

Earlier quoted context omitted.

> ...but, hot damn. More excels? Please no. Excel already exists. Don't rebuild that stuff again. I don't think they literally meant another Excel. Just something that is easily accessible and usable by non-programmers to do very 'programmy' things, etc.

This argument also just assumes, 'anyone can sit down and use excel'. Which is not true, excel has a learning curve like anything else, most people learn 'just enough' to do their job, maybe there is a guy in their office that knows a little bit more and they can learn from them. But excel proficiency acquisition is very similar to a programming proficiency acquisition, maybe the track runs out faster (at some point…

But it's way more discoverable, which is something that most "programming languages" of course, don't do at all.

Re: Programming breakthroughs we need

#465
post #235

The whole "program is a model" part makes me think of Smalltalk's image-based system. I never really got used to programming this way myself, but I do think an image-based environment might check some of the author's boxes. With the right tooling, a Lisp might even be a decent choice.

For those wishing to experiment what a current image-based development environment feels like, I recommend Pharo. Probably is the most advanced open-source development environment in the tradition of Smalltalk, available today. Main site: https://pharo.org/ MOOC: https://mooc.pharo.org/

I tried to go through the Pharo mooc and learn a bit, but dealing with bugs and jank in an complex and unfamiliar UI made me drop the idea pretty quickly. The object orientation aspect of it was interesting, but I just can't get behind a language which is tied so deeply to the use of a poorly maintained UI. At a first glance I'm liking the approach offered by Unison, where you work with an image but everything you need can be done from the terminal, which I think is much easier to maintain and make portably. Creating a nice UI for it can be treated as a separate problem.

Re: Programming breakthroughs we need

#466
post #9

Eh, unfortunately the one programming breakthrough the world actually needs is one that would drastically change, and perhaps harm, most of the people around here. We need more "Excels." More and better tools that let "regular" people program.

Simon Peyton Jones put some work towards that:

https://www.microsoft.com/en-us/research/podcast/advancing-e...

User defined functions:

https://www.microsoft.com/en-us/research/blog/lambda-the-ult...

Re: Programming breakthroughs we need

#467

Earlier quoted context omitted.

I programmed in Delphi for years and have done some toy things with Lazarus, so I'm painfully aware of the quality and reliability difference. It is quite bizarre how us programmers, who make hundreds of thousands of dollars per year, are unwilling to pay $1,400 that will make us more productive.

I make $0/year, so my choices are more restricted.

How about the Delphi community edition? https://www.embarcadero.com/products/delphi/starter

You can use it for free util your revenue reaches $5,000.

Re: Programming breakthroughs we need

#468
post #385

Earlier quoted context omitted.

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

This looks very cool and pretty similar to what I was visualizing. I'll have to download it and play around with it for a bit :)

Re: Programming breakthroughs we need

#469
post #385

Earlier quoted context omitted.

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

Yes, like crocodile clips for a circuit board, I can insert a probe into a circuit and see what's on the wire. When your callstack is 50 methods deep and there's 20 layers involved and marshalling and it's difficult to see what is going on. I want to mark two pieces of code and see the data structures passing through them, similar to a debugger but more like a log file or trace like Jaegar or Kibana. But the actual P…

This is a great analogy and captures what I meant very clearly! It would be awesome to pinpoint two pieces of code and ask for the execution flow visualizer for that path :)

Re: Programming breakthroughs we need

#470

Earlier quoted context omitted.

> patterns and flows and data models and extensions Might I suggest that you could probably try some Clojure and see how it goes.

I'm sure Clojure is very exciting for Clojure fans…but afraid it's utterly inscrutable and unreadable to me.

Can definitely understand that. I’m a big fan of Ruby myself and I use it quite often, and for sure at first readability of a lisp syntax seemed like a problem. I will just note that at some point I’ve realised that while Clojure can seem to be quite freeform, in fact it has very strict structure, which helps a lot.

I suppose that if somewhen you could get into it, you would find a rich toolbox with a lot of heavy lifting done under the hood and a lot of space left for you to think about application design first and foremost, with a fair performance.

Post reply on HN