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

491–500 of 511 posts

Re: Programming breakthroughs we need

#491

Post by midoridensha »

_gabe_ wrote: post #385
CodeMage wrote: post #357

Earlier quoted context omitted.

Maybe I'm just an old curmudgeon, but it seems to me there's way too much emphasis on speed of development in general. Time to market seems to be more important than quality, robustness, security, performance, or any other concern. 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've yet to meet a mathematician who wants to get completely rid o…

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

I've felt like this for a very long time, and it's disappointing that there aren't really any tools to do this yet. It would make it so much faster to come up to speed on a new codebase, and also to see where some potential problems might lie.

Re: Programming breakthroughs we need

#492

Post by samsquire »

_gabe_ wrote: post #469
samsquire wrote: post #439

Earlier quoted context omitted.

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

Thank you for sharing your idea with us :-)

Re: Programming breakthroughs we need

#493

Post by barrysteve »

bluejellybean wrote: post #403
fleddr wrote: post #342

I believe already some 2 decades ago Bill Gates said that the biggest failure in software is the lack of productivity gains in software development. Just to cherry pick a dramatized example. In the late 90s, one of my first programming experiences was in Delphi. It's a very visual way to program. You drag and drop a UI together from standardized elements. You could data bind things like input fields to a data source.…

The web, and much of programming really, feels so far behind the curve of what's possible as a programmer. Take a dive into shader design in something like unreal engine 5, it sounds exactly like what you're describing in Delphi, mind you, I say this as someone who has never programmed in that language. The ability to drag and drop functions, compose higher levels of abstractions, and really all of the fun programmin…

I've used UE4 for years and the Blueprints system doesn't save you much. Those abstractions are bricks, made for building brick houses. If you want to build something made out of anything other than brick, you're back to custom HLSL nodes and better off programming your shader somewhere else.

Blueprints are nicer for known problems, they are a better glue for old knowledge, but when you want to do something custom or new, you're out of luck.

This is the same problem with all programming, you can't make something specific and new without doing an engine teardown and rebuilding it. All the parts are terminally interconnected and always will be.

At the end of the day, UE4/5 is a landing pad for all the work you make in other tools. I agree web dev is no fun though.

Re: Programming breakthroughs we need

#494

Post by cutler »

OkayPhysicist wrote: post #130
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 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…

Just because Ruby acolytes Dave Thomas, Jose Valim and Chris McCord championed Elixir that doesn't make it Ruby's successor. The languages are poles apart beneath the surface syntax. Crystal has more of a genuine claim. I also think Kotlin is a relevant language for re-writing a Ruby codebase.

Re: Programming breakthroughs we need

#495

Post by mtVessel »

Banana699 wrote: post #217
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?

>This is only feasible if the program takes no input, or a very limited set. One of the insights that people making tools for dynamic languages discover over and over again is that most uses of dynamic features is highly static and constrained. In general, yes, a python program can just do eval(input("enter some python code to execute :) \n>>")), but people mostly don't do this. People use extremly dynamic and extrem…

> wouldn't it be better to record this and make it available at static write-time

I think you misunderstand my position. It's better for the creator to simply specify it when they write the code - i.e. static typing.

> the type profiler makes no attempt whatsoever at discerning the "meaning" of the data

Your examples are waaay beyond what I need or expect. What I need is for the program to recognize that, for a number, 123 and 456 are valid, but "abc" will never be. Conversely, for an identifier, no matter how many runs use values like 123, someday someone might provide the value "abc" and that's ok. Also, any code that attempts to sum up a collection of identifiers should not be runnable, even if the identifiers in question all happen to be numbers.

This is something that static typing provides, and no amount of profiling will ever be able to divine.

> In the vast majority of cases, you will find that your brain already has a very specific type in mind for each variable

Sure, for the code I write. But I've seen plenty of code written by juniors where, upon inspection, it was completely inscrutable whether a given parameter expects an integer, a string, a brick wall or a banana.

Which is all to say that my default position is unchanged: dynamic typing is unhelpful for anything larger than small, single-purpose scripts.

Re: Programming breakthroughs we need

#496

Post by riskable »

fullstackchris wrote: post #394
riskable wrote: post #167

Earlier quoted context omitted.

> Robust, comprehensive libraries from reliable vendors Hah! In all my years the biggest, most difficult vulnerabilities/problems to remediate all came from vendor-made (90% of the time closed source) software. With the free, open source stuff the problems are usually very minor but even if they're BIG we'll pretty much always get fixes and deploy them faster than if we had to wait on a vendor. The more popular the O…

What language code is written in has little to do with how "flexible" it is. Or what did you mean? Refactorable? Readable? I don't immediately see what the choice of Python specifically has over other languages.

You've got the wrong word. I said, "fixable" not "flexible".

Re: Programming breakthroughs we need

#497

Post by unixbane »

preseinger wrote: post #317
unixbane wrote: post #292

Earlier quoted context omitted.

Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and edit…

Semantic objects are non-dimensional. In fact they are probably best understood as simply ideas. Humans have been effectively incepting ideas in each other since the birth of language and writing. Text is, demonstrably, the best way to convey semantic ideas among human beings.

Woah there, it appears as if you are implying that text is demonstrably the best way to convey computer programs. Surely that's not what you're saying?

Re: Programming breakthroughs we need

#498

Post by unixbane »

thrown_22 wrote: post #316
unixbane wrote: post #292

Earlier quoted context omitted.

Programming is an exercise in manipulating semantic objects which is why stuff like blueprints in unreal engine are so easy to use. It will just get better and text will become an obsolete vestige, regardless of whatever idea you have of this being "harmful". I really don't think a character encoding with 30 ways to control the terminal (and now extended to encode emojis) is the be all end all way of writing and edit…

So what happens when you have a 10 deep nested if tree? Your answer would be to not do it because it doesn't fit nicely in a 2d page. My answer would be to put it in a 1d line and not bake semantics into presentation. But you can't pretend that the space of programs isn't infinite dimensional when the space we work in is only 3d. Regardless of how clever you are using a medium with a dimensionality higher than 1 for…

Just switch back and forth between box representation and graph. It's still far better than text. Text fails far faster. Have you ever used IDA? It shows a graph view of assembly based on jump flow instead of a linear assembly listing. Of course you can't magically understand all programs just with a simple algorithm to format them a certain way, but it's still immediately obvious that this is better. Most code is immediately understandable just using a C#/Java decompiler or gofmt without the programmer needing to format it. I just see variable names and formatting as spam and red herrings. Anyway you can't audit code by taking the programmer's word that he formatted it a certain way, so this whole "text for writing a poem of comprehension" idea is moot and outdated at least 30 years ago anyway.

Re: Programming breakthroughs we need

#499

Post by unixbane »

the_af wrote: post #108
mikewarot wrote: post #83

Earlier quoted context omitted.

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

No post body was provided.

Re: Programming breakthroughs we need

#500

Post by unixbane »

plafl wrote: post #306
ecopoesis wrote: post #284

I would love to see a language that considers tooling a first class problem. Most (all?) languages barely consider complex projects with 100s of dependencies and large multi-step builds. Java shouldn't have to wait for Maven and Gradle to come along, and Python shouldn't be shackled to piss-poor systems like pip. This is something Rails gets very right. Bundler and Rake make Rails one of the nicest development enviro…

>But we can and should do better. Why is DLL-hell still a thing? Imports should specify versions, defaulting to a default if none is specified. Languages barely even consider versions today, they are almost always hacked on via magic text strings in filenames. So suppose you fix the version number when you import the library. You then need to copy paste the version number to other imports in your code base? Or maybe…

No post body was provided.
Post reply on HN