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

101–110 of 511 posts

Re: Programming breakthroughs we need

#101

Post by gervwyk »

Excellent insights in this article.

I've approached building web apps as data models. It works really well for our team. This was how / why we started to develop Lowdefy [0], to express a web application with a data model. We've been experiencing the benefits of this - I really need to start writing about it.

Writing this app model in json or yaml might not be ideal start, but once you have that creating a IDE / GUI builder / next thing on top of that becomes really a simple task while reaping all the benefits of defining an program / app as a data model.

[0] - https://github.com/lowdefy/lowdefy

Re: Programming breakthroughs we need

#102

Post by the_af »

Lichtso wrote: post #95
the_af wrote: post #78

Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editin…

Actually, I think we have already moved away from pure text a long time ago. Think about it this way: If "text" (so only the sequence of tokens) was the valuable representation, then we would all program without any formating (no additional spaces and linebreaks). Now, you might say well formating is important for readability. These spaces and line breaks do matter. But, just adding them randomly where they are synta…

Thanks for the thoughtful reply.

I think what you call formatting is an essential part of textual representation (alas! It's also the most contentious part). After all, formatting is an essential part of how we write and read novels, articles, etc.

In this sense, I think text with formatting is pure text... for human consumption.

I am arguing it is the ultimate representation: for historical reasons, of course, but also because there is less friction with tooling, less vendor lock in, fewer standards that must be developed and adopted universally, etc.

Re: Programming breakthroughs we need

#103

Post by baq »

tppiotrowski wrote: post #96
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…

Working on old but popular software is where legends are made. You need to be methodical about changes. How do you make changes in a million line+ codebase without breaking anything for millions of existing users? This challenge is reserved for the finest engineers on the planet. These are the people you want your desk near when you start your professional career as a programmer.

this is simpler than it sounds - the process trumps any engineering stardom. the process is king. the process is love, the process is life, quite literally. getting any change in there isn't so much fine engineering as it is wrestling with layers and layers of process, where every layer has been added due to a monumental f-up in the past. it's an environment where getting any change committed into a repository usually takes weeks, unless one of processes for sidestepping the process is invoked.

Re: Programming breakthroughs we need

#104

Post by BlargMcLarg »

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…

Pretty sure I speak for a majority of experienced devs when I say: we don't fear abstractions. We fear abstractions made by others, including our former selves, in the all to often occurring context of "business wants it done by yesterday and we have zero idea what the requirements actually are". All the while we're still figuring things out and having 30 minute discussions on the most miniscule things.

Re: Programming breakthroughs we need

#105

Post by heurisko »

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.

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.

Re: Programming breakthroughs we need

#106

Post by 082349872349872 »

foolfoolz wrote: post #54
zwkrt wrote: post #6

There’s a lot of complaining and not a lot of suggesting going on in this article so I don’t take it for very much. I feel like the author got a job and realized that it almost exclusively involves writing glue code and tests and looking at text diffs, so how convenient to imagine a world where they didn’t have to do the boring parts of their job.

very much agreed. i don’t like the term glue code. when people say glue what they usually mean is their applications specific business logic

a Shannon-inspired taxonomy (note the indefinite object; ymmv):

- glue code: given the outputs, you can reconstruct the inputs. this code translates between formats, between systems, etc.

- parsley code: given the outputs, you could reconstruct the inputs. this code "gussies up" its inputs: it takes table rows to JSON, or JSON to framework objects, PDF, etc. so in principle the original data is still there, but once the outputs are sufficiently complex the inputs become extremely awkward to reconstitute.

- crunch code: given the outputs, you have no hope of reconstructing the inputs. this code does real computation, and forgets stuff. Example: You can get a source program given only an executable, but you won't get the source that it was compiled from (nor will you, without a lot of work, even get a source you're willing to read)

Re: Programming breakthroughs we need

#107

Post by disantlor »

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 dont fear magic as much as magic* where the * is all the exceptions that had to be hacked into the magic to make it work on the slightly different use case than what the magician dreamt up

Re: Programming breakthroughs we need

#108

Post by the_af »

mikewarot wrote: post #83
the_af wrote: post #78

Everytime someone proposes a non-textual representation of code I cringe. There's a reason no one single alternative has triumphed over text. And many have been proposed! Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editin…

>Standards are hard. Proprietary tools lock you in. Text is universal (OK, restricted to plain ASCII, which is a big deal but has already happened). You can open and modify a text file with whatever editor of your choice, the simplest possible editing tool. Some weirdos (joking) even print source code. Ideas are impossible to specify precisely, which is why we use words, with all their myriad definitions. However, if…

Thanks for your reply!

I'm not sure if this is what you're saying, but I think the AST is not meant for "human" consumption (so it'd be outside the scope of this debate, I think), but also, translations that result in alternative and radically different representations between what you see and what I see can be problematic.

"I don't understand your program, it's hard to follow."

"What do you mean? The yellow and black colors alternate quite nicely."

"Colors? What do you mean? I only see triangles arranged in a jarring manner, and they are hard to navigate."

"Navigate? Everything fits in a single board of yellow and black colors, no need to navigate anything."

Etc.

Re: Programming breakthroughs we need

#109

Post by graycat »

Fundamental, foundational, unavoidable, overwhelming, invincible but just dirt simple truth: Please sit down for this. And may I have the envelope, please? Drum roll?

===>>> In computing, meaning is crucial. Computer source code doesn't mean anything. Computer code obeys strict syntax rules, but those rules do not give meaning.

So far, sorry 'bout this, essentially, to date, there is only one good and significant approach to meaning -- writing in a natural language, e.g., English. Did I mention, sorry 'bout that.

In simple, blunt terms, in well written code, the comments which provide the meaning are more important, especially for maintenance, than the actual code that gets executed. Sorry 'bout that. Beyond that, beyond any doubt, far and away, in well done software, the most important part is the well written documentation. I should put this word documentation in all caps, ultra bold face, with flashing lights -- well written documentation.

Sorry 'bout that.

For my code for my startup, early on I wrote out some documentation in TeX, with the crucial core pure/applied math, data handling, etc. Then I wrote some notes about the code. The code is just awash in documentation, 100,000 lines of typing and 24,000 programming language statements. Right, on average 4 lines of typing for each programming language statement.

I had some external events pull me off the work of my startup, but now I'm returning to it and finding my old documentation just crucial, terrific. Even though it is all my project and code, I still need all the documentation, and it works great -- let's me understand again right away.

Don't believe me or argue with me. Instead, learn from D. Knuth who has demonstrated very well that he is really good with software. See what he did, and how and why, with his literate programming -- more like reading a book in English about something in engineering than just source code.

Right, long many software projects at IBM and the US DoD went through stacks and stacks of layers of planning, requirements, specifications, ..., before any code was written. Then for any change, might have to go through the hundreds of pounds of paper of the documentation to get it up to date again -- a real pain, bottleneck, boat anchor to progress, etc. Right. Need a better way. But apparently their documentation process was too clumsy or some such. On the other hand, if the software is for an airplane and it is you who is going to fly on that plane, then maybe ....

Net, the meaning is crucial, and the code doesn't mean anything. The meaning is in the documentation written in a natural language, e.g., English. Sorry 'bout that.

One more point: We can try, but I see little hope soon. We can try to design a programming language with syntax so expressive that the meaning is automatically obvious and no more documentation is needed. Did I mention I see little hope soon? Sorry 'bout that.

Post reply on HN