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

331–340 of 511 posts

Re: Programming breakthroughs we need

#331

Post by yifanl »

Tao3300 wrote: post #221
yifanl wrote: post #171

Earlier quoted context omitted.

> Elixir is pretty widely considered to be the Ruby successor. Really? That feels really odd, once you get past the surface level syntax, Elixir doesn't really resemble Ruby to me, unless you've conditioned yourself to write purely functional Ruby?

Here I thought it was a gateway drug into Erlang

You can certainly treat it as a nicer interface into the BEAM VM, but it's certainly possible to never write a line of Erlang while being an amateur Elixir developer.

Though I'll have to defer to others if its also possible as a professional.

Re: Programming breakthroughs we need

#332

Post by bmitc »

vlunkr wrote: post #305
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'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 actually a place where I produced the most useful work.

If the number one answer to we're using Agile but it's not working is "you're doing Agile wrong", then maybe Agile isn't the solution?

The way I worked at the place that did not have an explicit process was one of switching between agile and waterfall methods. Early on in the projects, the process was primarily waterfall, defining things up front, building prototypes, laying out the project, etc. Then once passed that stage, projects would enter into a more agile or iterative process. Then as new big features came in, back to waterfall and then switching to agile once that stabilized. This worked quite well.

Re: Programming breakthroughs we need

#333

Post by glass_of_water »

preseinger wrote: post #319
david927 wrote: post #234

Earlier quoted context omitted.

I couldn't disagree more. You don't buy a drill, you buy a way to get a hole in, say, wood. That's the core product. The core product of 'programming' is a software solution. So far, the best way to approach it is text. But... text is an incredibly poor model! It's almost literally an accounting system of "Jake spent fifty dollars." It's text which is "actively harmful," and we see it all around us in the absence of…

Programs are ideas that need to be understood, modeled, and manipulated by humans. Text is the best available way to incept ideas into the minds of humans.

If that were true, text books wouldn't contain any diagrams. So I think it's fairly uncontroversial to say that there are cases when text is not the best way to incept ideas. So why should we be confined to just text when writing code? Should we not be free to choose the best tool for the job?

Re: Programming breakthroughs we need

#334

Post by [deleted] »

wizofaus wrote: post #232
bcrosby95 wrote: post #170

Earlier quoted context omitted.

It's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.

2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.

[deleted]

Re: Programming breakthroughs we need

#335

Post by AndyMcConachie »

agumonkey wrote: post #280
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 sincerely don't know why uni don't make more classes on that only. - pick any software - try to change something - give a precise impact analysis - generate a few potential implementation paths - measure how fast you did all that and what failed / worked

I agree.

A fundamental problem with how we teach programming is that we focus on writing, instead of reading, software. To borrow terminology from the language arts; we don't focus enough on reading comprehension.

Re: Programming breakthroughs we need

#336

Post by teleforce »

I'm surprised that the author did not even mention about GC and I think it's another programming breakthrough after structured programming.

Currently GC for compiled languages like Go and D (optional) are considered as disadvantages rather than an advantages for high performance systems.

Perhaps if we can get AI enabled GC that has good performance as manual memory management in C++ and Rust it will be a genuine breakthrough for modern programming languages.

Re: Programming breakthroughs we need

#337

Post by the_af »

unixbane wrote: post #303
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…

Standard boomer rant. > There's a reason why the status quo exists Yes, it's called the status quo. > text is universal Which one, ASCII, code page 9000, or UTF-8? Are you saying just restrict to ASCII? Then we need custom solutions every time someone wants to talk a different language. > lock in I am locked into using retarded insecure terminal emulators because all my tools depend on it to render what you people ca…

> Standard boomer rant.

Please stay polite. I'm not a boomer and my comment wasn't a rant.

> Yes, it's called the status quo.

I didn't mention the "status quo", please don't misquote me in order to make a clever retort.

> Which one, ASCII [...]

I preemptively mentioned which one, which defuses the rest of your sentence. More importantly, you know which one I meant. And I know you know, so please, let's not argue this.

> I am locked into using retarded insecure terminal emulators [...] Even vim breaks from unicode already

None of this has much to do with what I wrote. Again, I must ask you to stay polite and on topic. If you dislike your tools, use better ones.

> The primitive language of the OS should not be some poorly defined idea of "text", but algebraic data types.

This discussion is about representations meant to be universally understandable by programmers, i.e. humans, not by the OS.

> [reading] is better done by graphics that text

Reading is mostly done using a special kind of "graphics" called "text". People with disabilities or who are busy doing something else, like driving a car, choose alternatives; but let's be honest, most people read text.

Re: Programming breakthroughs we need

#338

Post by [deleted] »

Jensson wrote: post #244
tasuki wrote: post #193

Earlier quoted context omitted.

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

Many dependencies? Updating them is hell, remove dependencies and just write the utilities we need so we can update to latest easily! Few dependencies? Too much reinventing the wheel, delete all that code and add dependencies! There is no perfect code, can always make different trade-offs and move things around.

[deleted]

Re: Programming breakthroughs we need

#339

Post by [deleted] »

wizofaus wrote: post #232
bcrosby95 wrote: post #170

Earlier quoted context omitted.

It's not complexity. It's pointless bookkeeping. If you don't cut corners on your static typing, you're looking at 2-4 single use classes per API endpoint: 1-2 for the web layer, and 1-2 when going into the domain logic layer. Many people skimp and just re-use the core domain class for everything, which is the worst of both worlds. I'll take a map, spec, and select-keys over this all day long.

2-4 single use type definitions per endpoint sounds pretty atypical to me, but I agree choice of language helps here, e.g. TypeScript has pretty powerful typing facilities (Pick/Partial etc) that make type reuse far more practical. It's bookkeeping yes, but definitely not pointless.

[deleted]

Re: Programming breakthroughs we need

#340

Post by vlunkr »

jrockway wrote: post #224
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.

Yeah, I think this is what a lot of people miss. When I only used dynamic languages, I told everyone that they were the greatest thing ever and they were idiots for using static languages. Then I started using static languages and would never go back to dynamic languages. (OK, I still write Emacs Lisp.) All the things I thought were great about dynamic languages were actually a huge waste of my time, but I didn't kno…

> even if it does save me time today when I'm typing in the code

IMO this is the strength of Ruby/Rails. You can have something up and running incredibly quickly, but for complex applications it can easily become a mess. It's not easy to know where something is defined, what type it is, if it can be nil, if you're unknowingly calling the database one or one hundred times with your fancy one-liner, etc.

Of course you CAN structure it all nicely beforehand, and even use type systems, but that's hard to get right, and at that point, you might as well use something else.

Post reply on HN