201–210 of 511 posts
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…
That and that everyone adopts it so there's plenty of libraries and a community :D.
Seems like Clojure will get there with beefed up REPL workflows ala Calva/Portal. Community is amazing rn but tbd how it 10-100x (if ever).
On the backend, it's nothing new. Just use functions and problem solved.
> Program is not a text, [it is] a model I don't think so. In fact, I think this perspective is actively harmful. A program is whatever the human beings who maintain that program operate against. I mean there are many possible representations of a program, and there are different ways to evaluate those models, but the model that most precisely expresses the AST of the logic of the program, or the call sequence of the…
foreach item in list_A
do_something(item)
The transformer part is super hard if we rely on automatic tools, which is just another version of a compiler. It is super tedious if we rely on human manual work, which is just how today programmers do. But if we view the transformer part as part of programming, where programmer employs tools to mold their program, then it makes sense. The programmer will be able to program the tools to avoid the tedious part but still with full flexibility to mold anyway they desire. It is still programming, but in a meta frame where text is the target.
Earlier quoted context omitted.
> It's way-ay-ay more effort Just because you tend to ignore the many complexities that are actually involved in a form on a web page. It's exactly this bias that stems from untyped languages and that needs to die. Http is a complex beast and we should either replace it with something more simple and robust or at least acknowledge the complexity in our programming. Generally speaking, if doing something with a proof…
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.
Earlier quoted context omitted.
Oh really? Suppose x = 123 and x = "123" were "THE SAME THING". What's x + "42"? What's x + "042"? What's x + "a"? What's x + "e2"? What's x + "e2" + 12345? What's x + "1,500"? What's 1 / x?
To be fair, that's more weak vs. strong and not static vs. dynamic. You can have a dynamic typed language where all these are cough runtime errors.
> I feel like we will continue to run into these kinds of issues to the end of time unless can figure out: 1. How to precisely describe the properties we want the final system to have, 2. How to 'compile' from a higher-level language/layer into a lower-level language while maintaining all those properties. At the least this will require us to: 3. Define the precise semantics of each layer and enforce that every construction in and implementation of that layer adheres to it strictly.
> Layers/languages should verifiably maintain these properties through every translation via paths like: eula/privacy policy, requirements, UX, UI, state machine, source code, AST, IR, ASM, machine code. Every one of these layers should have a well-defined execution model that is isomorphic with other layers, modulo metadata. For example: source code === AST [+ comment/whitespace/filesystem metadata], AST === IR [+ name/desugaring/applied-optimizations metadata]. All undefined behavior at every layer must be exterminated by definition or avoided by construction.
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?