Programming breakthroughs we need • Hacker News Board

Re: Programming breakthroughs we need

#191

Post by codereviewed » Wed, Aug 17, 2022, 6:19 PM UTC

mrguyorama wrote: post #153

dehrmann wrote: post #82

Earlier quoted context omitted.

I was agreeing with you, but as I thought about it, I remembered MS Access. It is used, often ships with Office, but still isn't close to as popular as Excel. Either the model is wrong, or the need isn't there.

Access used to be pretty standard for a small business trying to improve their situation, but we in the software development world spent so much time trying to work around limitations of Access and upgrading growing businesses out of Access that we took it personally and shouted to everyone not to use Access. However, it is still taught in IT classes as a useful tool for small businesses, and it is.

My very first paid web gig was connecting a small business' Access based product catalog to their website. I was 14 or 15 at the time. I was able to do it with out any real coding knowledge except for some basic HTML I learned from MySpace and some copy-paste VBScript, haha. The site was a hit and I made $1,200 and immediately spent it all on an electric guitar.

Re: Programming breakthroughs we need

#192

Post by loquisgon » Wed, Aug 17, 2022, 6:20 PM UTC

The essential complexity in today's coding is that code is created by humans. Therefore humans, we have to understand existing code bases to modify them and this is non-trivial. We also have to understand "what" needs to be built, that is the infamous "requirements". I think eventually coding will be automated away with artificial intelligence. I did not think like this for a long time in my career (that programming will be automated I mean) but neither I thought that computers would be able to create "deep fakes" and things like understanding & speaking human languages.

Re: Programming breakthroughs we need

#193

Post by tasuki » Wed, Aug 17, 2022, 6:23 PM UTC

metaltyphoon wrote: post #180

deepakkarki wrote: post #142

Earlier quoted context omitted.

Or the difference between conceiving a child and raising one :)

I always smile when a green field project starts and then they claim its “Clean Code”. No, you won’t known if it was clean code until years down and the system will need updates. Then and only then you can reflect and see how hard it was to changes things in it.

Fully agreed. No matter how "clean code", the next person or team is immediately going to label it "legacy" and complain endlessly about all the choices made by the original author(s).

Re: Programming breakthroughs we need

#194

Post by sleepybrett » Wed, Aug 17, 2022, 6:24 PM UTC

ziddoap wrote: post #41

wokwokwok wrote: post #24

Earlier quoted context omitted.

I'm not going to argue whether the 'world actually needs' that, or if people mostly, actually want that, or if, since excel is already there if you want it, you probably don't have to write, sell or build any more low code tools. ...because, although I could argue about those points, it's fundamentally unrelated to the OP, and issue that programming is hard, and, for a very long time, no one has really had any idea h…

> ...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 you reach real diminishing returns and limits to a spreadsheet's capabilities but I've seen some insane shit written in excel, raytracers for instance, but no-one who has done that thinks it's a good idea.)

Re: Programming breakthroughs we need

#195

Post by herdrick » Wed, Aug 17, 2022, 6:25 PM UTC

mtVessel wrote: post #190

Banana699 wrote: post #88

Earlier quoted context omitted.

I think dynamic analysis is incredibly powerful and criminally underused in IDEs and other dev tools. I have thought of an idea about 6 months ago that has been fermenting in my mind since then : what if (e.g.) a Python VM had a mode where it records all type info of all identifiers as it executed the code and persisted this info into a standard format, later when you open a .py file in an IDE, all type info of the o…

This is only feasible if the program takes no input, or a very limited set. Once you open it up to arbitrary input, no single run (or even a large set of runs) can capture everything the program might be expected to handle. How does the type profiler know that the variable that only contained values like "123" or "456" was handling identifiers , not numbers?

Correct, that's why you use the large dataset available to you -- tons of runtime data from production.

Re: Programming breakthroughs we need

#196

Post by sleepybrett » Wed, Aug 17, 2022, 6:25 PM UTC

swatcoder wrote: post #71

mynegation wrote: post #50

Earlier quoted context omitted.

What is your alternative then? Vendored-in dependencies with their ossified security vulnerabilities? Or figuring out homegrown code of dubious quality for the functionality that is not core business of the company/product?

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…

... thoughtful, experienced engineering like log4j?

Re: Programming breakthroughs we need

#197

Post by fuzzy2 » Wed, Aug 17, 2022, 6:28 PM UTC

cannabis_sam wrote: post #163

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…

>Static typing everywhere. It's utterly baffling to me. I find it far more baffling that people don’t want to offload the trivial parts of the mental work of ensuring the programs they write makes the minimum of sense. I also jumped on the dynamically typed bandwagon after using low value type systems like java’s, but after using haskell, ocaml, typescript, purescript, rust, and especially elm, I realized that they l…

I also like statically typed everything. But I have to admit, some of the more adventurous stuff people do with JavaScript (that just works because it is dynamically typed) is pretty ergonomic. Even with TypeScript it is often next to impossible to make it strongly typed.

I guess Ruby or even Ruby on Rails is very similar, with the ability to monkey-patch just about everything.

Some things are just better (left) dynamically typed.

Re: Programming breakthroughs we need

#198

Post by ablob » Wed, Aug 17, 2022, 6:28 PM UTC

preseinger wrote: post #174

> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…

How is it harmful?

> A program is whatever the human beings who maintain that program operate against

This does neither invalidate the statement that "Program is not a text", nor that "[it is] a model".

> And for the moment that's source code.

How is wanting to change that harmful? Source code can have flaws like ambiguity (see C++'s need for typename). Deeming a call for improvement on the existing representation of a program harmful is a fine way to stop any progress at all. We would still be putting in raw numbers into memory with that attitude.

On another note: I think what matters is what the computer actually does. Whatever I, as a human, read and interpret has no meaning at all if the computer decides to "read and interpret" it differently. And the only limit with representing what the computer actually does should be your imagination.

Re: Programming breakthroughs we need

#199

Post by tasuki » Wed, Aug 17, 2022, 6:30 PM UTC

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.

> way-ay-ay more effort for dubious gains

How is it way more effort? In any of the nicer languages, there's type inference.

Dubious gains? Strong static typing makes entire classes of runtime bugs impossible (null pointer exceptions, for example).

Re: Programming breakthroughs we need

#200

Post by sleepybrett » Wed, Aug 17, 2022, 6:31 PM UTC

galaxyLogic wrote: post #154

I've often thought about similar idea(s), the program is constructed out of nested components, almost like LEGOs. When we play with LEGOs we don't need a "programming language". Or do we? But what is a "language"? It is a set of "legos" of different types like 'verbs', 'nouns', 'adjectives' which can be combined in many different ways, but only according to the lego-rules of syntax. Some lego-pieces can not be combin…

Lego created a visual programming language for their mindstorms system that is exactly this. It's very similar to scratch and while it lets you get things done and you can build some pretty amazing things with tools like that. The ... second order tooling... just isn't there. We have a huge amount of tools running around that can deal with code as text, but there are no analogous tools for these visual programming environments.

I've dug into some of these tools in the past, wrote some projects using things in the 'creative coding' space like quartz composer, touch designer, vvv ... at a certain point the visual clutter gets you and, at least in my experience, it was just faster to rewrite in a creative coding framework like openframeworks/c++.