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

451–460 of 511 posts

Re: Programming breakthroughs we need

#451

Post by Ygg2 »

hutzlibu wrote: post #445
magic_hamster wrote: post #440

Earlier quoted context omitted.

In game engines, and especially in UE where things like Blueprints exist, the low level stuff is just conveniently hidden or abstracted away. But the long textual code that makes the button work, eventually exists somewhere in there. At least when you write it yourself, you know who to blame (and probably where to look) when it doesn't work.

"the low level stuff is just conveniently hidden or abstracted away. " Yes. This this is exactly what I want. When I write an engine or framework, I will deal with low level stuff. But for basic tasks, I don't want to. But I have to, even where it would not be necessary. "But the long textual code that makes the button work, eventually exists somewhere in there." Also there exists even longer textual or even binary c…

> Yes. This this is exactly what I want.

But the more abstract you go, the less efficient does your editor become. And speed of development goes down. It's not a simple - just put more abstraction.

Re: Programming breakthroughs we need

#452

Post by Ygg2 »

andsoitis wrote: post #417
saghm wrote: post #384

Earlier quoted context omitted.

"No standard library" might be too strong a criticism, but "a dozen or so built-in global variables with various methods" is still probably not the user experience that most desire.

What would you put in the JavaScript library?

See Python (for feature rich version) or Rust (for less feature rich standard lib).

Re: Programming breakthroughs we need

#453

Post by Ygg2 »

simonblack wrote: post #349
tacitusarc wrote: post #273

Earlier quoted context omitted.

My metric for clean code is how quickly a developer unfamiliar with it can understand it

Much as we denigrate COBOL, that is still its greatest advantage. Yes, it's wordy, yes it's old. Yes, it needs to be really updated. But it's still easier for a new hire to understand the COBOL old code than any other old code.

I've never had any problem digging into any Python codebase.

Even magic stuff like `@attributes` is easily searchable.

Re: Programming breakthroughs we need

#454

Post by zelphirkalt »

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.

Actually typing in PHP is not really static. Errors are thrown at runtime, afaik. There might be separate tools, which check the types before running the program, but they are not PHP itself. That aside, I think part the reason, why static typing brings so much to the table in languages like PHP and JS (in form of TypeScript) is, that they are rather weakly typed and not strongly typed. Weak typing and dynamic typing can make for a terrible DX, when bad designs are present like they are a lot in PHP and JS.

I like static typing personally, but for example have no issue with using a strongly typed language, which does not allow me to treat a number as a string or string as a number or similar. Often such a language provides means of making things safer at runtime at least. For example one can define structs and functions, which only work, when they get an instance of that struct. Any other type of value would result in an error. Then of course there are unit tests, which can cover a lot of ground, even if not all a type system can do in theory.

Re: Programming breakthroughs we need

#455

Post by panstromek »

dotopotoro wrote: post #361
glass_of_water wrote: post #333

Earlier quoted context omitted.

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?

You should check out IDEs :) IDE takes plain old text as input, and lets the coder to interact with the model of the program. 1. Various graphical hints in text (highlighting keywords, selections, …) 2. Visualisation tools (draw database and class diagrams) 3. Navigation capabilities (go to implementation, definition etc) 4. Refactoring capabilities (“rename, “extract variable”, …) In my view, IDE is already “book wi…

True, but IDEs are currently severely limited by nature of textual sources (e.g. macros are notoriously tricky to deal with). It's much easier to start from a good model for IDE and derive textual reprentation and input method from that.

Re: Programming breakthroughs we need

#456

Post by samsquire »

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…

I spend everyday thinking of what my computer could be doing.

Most of the time the CPU is waiting for IO - memory, network, SSD, disk and not doing any work.

You might like my idea called GUI Thunking.

https://github.com/samsquire/gui-thunks

Re: Programming breakthroughs we need

#457

Post by panstromek »

jmull wrote: post #276

The author wants to do away with the program as text source code but doesn't suggest another way to represent a program. You're going to have to perceive and manipulate your program in some way. Maybe it will be great to get rid of code, but then what will you have instead?

> The author wants to do away with the program as text source code but doesn't suggest another way to represent a program.

Quoting the article:

> I imagine this model as a relational database - you have tables like `structs`, `fields`, `functions`, `arguments` and relationships between them.

I really want something like that pretty specifically. We still use text to edit data in SQL database, but you can also use queries to view or manipulate it. That's the idea.

Re: Programming breakthroughs we need

#459

Post by panstromek »

bambataa wrote: post #210

Text does feel like a really slow way to work sometimes. A while ago in a React app I needed to keep some state around so lifted it from component state hooks to a context. Very mechanical work. It feels like we should be to say “move these to a context consumed by A, B, C” and just have it all done automatically. Is there anything inherent to React/JS that stops something like IntelliJ implementing that?

> Is there anything inherent to React/JS that stops something like IntelliJ implementing that?

Yes, actually. It's a problem for dynamic and weakly typed languages. IDE can't assume much properties about the program so it can't do many of the refactorings reliably. On top of that, React and many web frameworks build on some DSL (like JSX) and build-system specific project structure and source transforms that the IDE can't reason about very well. As a result, such refactorings often need to be implemented by the IDE for each specific framework separately. This is exactly the area where starting with a semantic model first would help a lot.

Re: Programming breakthroughs we need

#460

Post by hutzlibu »

Ygg2 wrote: post #451
hutzlibu wrote: post #445

Earlier quoted context omitted.

"the low level stuff is just conveniently hidden or abstracted away. " Yes. This this is exactly what I want. When I write an engine or framework, I will deal with low level stuff. But for basic tasks, I don't want to. But I have to, even where it would not be necessary. "But the long textual code that makes the button work, eventually exists somewhere in there." Also there exists even longer textual or even binary c…

> Yes. This this is exactly what I want. But the more abstract you go, the less efficient does your editor become. And speed of development goes down. It's not a simple - just put more abstraction.

"It's not a simple - just put more abstraction."

Of course not. It is about the right level of abstraction.

Abstracting all the details away, I do not need to accomplish the task at hand.

If done right, this also will not slow things down, rather the opposite. Imagine programming a button in assembler and opengl. There you have all the details (and power). But chances are, you will be way slower and with a worse result, because you have to focus on other details and not on the task at hand.

Post reply on HN