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

221–230 of 511 posts

Re: Programming breakthroughs we need

#221

Post by Tao3300 »

yifanl wrote: post #171
OkayPhysicist wrote: post #130

Earlier quoted context omitted.

I agree with you that "Re-write your Ruby project in Rust" is a terrible suggestion. Pretty much only "Re-write your C++ project in Rust" makes any sense. But it's not all bad. Elixir is pretty widely considered to be the Ruby successor. Types are replaced almost everywhere by pattern matching, the widely accepted unexpected behavior response is to just not handle it, crash the "process" (green thread) and continue o…

> 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

Re: Programming breakthroughs we need

#222

Post by mcdonje »

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…

Sounds like you want more declarative languages, like SQL. The magic to get those to work well is a lot easier to implement and optimize if the problem space is restricted. So, DSLs.

Re: Programming breakthroughs we need

#223

Post by herdrick »

herdrick wrote: post #195
mtVessel wrote: post #190

Earlier quoted context omitted.

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.

It would seem like that's getting the types too late to be useful, but in practice most code goes into production in stages, so you could start getting this probabilistic typing data from code that has rolled out in a limited way, for example features that are hidden to most users.

Re: Programming breakthroughs we need

#224

Post by jrockway »

heurisko wrote: post #105
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.

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 know because I never really explored the other side of the world.

I have looked at modern Ruby projects, and my assessment is that I absolutely would never want to be responsible for code like that. It's all way too magical, if you see code that says something like "foo.bar", you really have no way of figuring out where the code for "bar" is. "bar" may not even appear as a literal sequence of characters in the application's codebase, or even in the libraries it includes.

If you like that, that's fine, but I wouldn't touch it with a ten foot pole. I don't find it that enjoyable, even if it does save me time today when I'm typing in the code.

Re: Programming breakthroughs we need

#225

Post by commandlinefan »

Aqueous wrote: post #39

I've thought about this issue so very many times, and I feel that until someone creates a system capable of understanding the underlying purpose of the code, we will not be able to automate this stuff away. I think the issue is that all of the things the author wants a breakthrough for is exactly what makes programming hard. We don't have systems intelligent enough to reason about a contract between two systems so as…

> we will not be able to automate this stuff away

We can't even automate testing of code (no matter how much "test automation" you have, you have manual testers too). That's orders of magnitude easier than automating the creation of the code in the first place.

Re: Programming breakthroughs we need

#226

Post by staindk »

dehrmann wrote: post #82
jrm4 wrote: 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.

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.

MS Access has awful UX. I've used it on and off over the years and can never find my 'flow state' as nothing in that program seems to flow at all.

If MS prioritised working on it it may have helped lift some people out of Excel and into DBA-lite territory but not in its current state.

Re: Programming breakthroughs we need

#227

Post by bjourne »

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 totally agree. When given the chance, (and if the goal is productivity) I always use Python because it is the most high-level and most productive language and ecosystem out there. I learned it almost 20 years ago and it was apparent after only spending a night or two with it that it was massively more powerful than Java, C and C++ which were the languages I knew at the time. Since then I have not discovered anything that was a similar improvement as Python was over Java. Concatenative programming comes close but suffers from small ecosystem and there are issues with the syntax.

Automatic memory management became mainstream in the 90's and dynamic typing in the 2000's. But what did the 2010's give us? Github and Stackoverflow? I think we are due for another "programmer productivity" revolution but I have no idea what it will be. Statically typed programming languages that are marginal improvements on existing dominant languages for sure aren't it.

Re: Programming breakthroughs we need

#228

Post by politician »

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…

Complaints about static typing boil down to not wanting to be responsible for the schema and data architecture of the program itself, and that desire to remove responsibility for designing the scheme is where ORMs like ActiveRecord find a foothold.

Unfortunately for folks and languages with this mindset, if they need to have good performance, eventually they will need to take responsibility for the data model of their database and their codebase.

Code is data, and types are schema.

Re: Programming breakthroughs we need

#229

Post by wizofaus »

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.

New downsides such as? And if having to add a few type definitions to your codebase is "way-ay-ay" more effort, I can only assume you really hate typing, as the mental effort is typically very low (compared to figuring out how to efficiently translate business logic into code, and how to organize code to make it easy for a team to work with over many years as requirements change etc.). There even tools that will generate type definitions for you based on sample data.

Re: Programming breakthroughs we need

#230

Post by UglyToad »

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…

I actually started writing a blog post along this theme but never got very far with it.

I'm not against code storage and representation as text per-se, merely that typing/editing it (text) is a not particularly efficient way of thinking about code.

A lot of people I'd characterise as 'words-per-minute is everything' style thinking are seeking the most efficient way to convert thoughts into text input. From punch-tape to mechanical keyboards the ultimate goal of programming language development is a 'faster keyboard'.

I think this focus on text input as foundational is incorrect. Most text isn't meaningful, the subset of meaningful text is severely constrained by the execution environment of the text. Outside of variable names and naming functions text input just isn't that interesting or important. For example unless you have previously declared one, invoking a function named `ttoString` isn't useful.

This is why I think coding outside some form of IDE (how far along that spectrum is up for debate, but I'd say autocomplete at minimum) is somewhat inefficient. Code is text, but it's also a layer on top of the text, the set of possibilities defined both by the text and the compiler/interpreter (or more specifically as you mention in your comment, AST). Treating code as text where you might rename a function with find-and-replace is frankly, daft and backwards. Your tools should rename the concept/symbol/whatever you're targetting specifically and they should understand your intent and meaning. By focusing monomaniacally on text we're ending up with worse tools.

This also scales to text input more generally. For some reason spell-checking doesn't work for me in Firefox so I'll have no doubt made a bunch of spelling mistakes in this post and it feels a considerably worse way of typing. I don't particularly value the ability to write "ocurence" since it's incorrect. I'd rather have tools that assist me communicating efficiently in a manner understoof (sic) by others. Text is fine but tools are great.

This develops into a more general objection to languages like Python/Ruby/JS but that's a whole other flamewar.

Post reply on HN