The link to at the bottom update post should probably point here https://ochagavia.nl/blog/solving-the-jit-calculator-challen... instead of back to the article
Readit Newsmitt_romney_12 commented on The JIT Calculator Challenge ochagavia.nl/blog/the-jit... · Posted by u/azhenley
mitt_romney_12 commented on Moving Beyond Type Systems vhyrro.github.io/posts/ef... · Posted by u/flexagoon
You don't have that API. You offer
x = read_guess(0)
y = read_name("what's your name: ", len(x))
z = read_guess(len(x)+len(y))
But now every function that reads from stdin needs to pass around an offset of where to read from which is very unergonomical. It also isn't really pure since offset is now state that is changing whenever a function is called.
fn do_stuff(offset: int) -> (string, int) { x = read_guess(offset) y = read_name("what's your name: ", offset + len(x)) z = read_guess(offset+len(x)+len(y)) new_offset = offset+len(x)+len(y)+len(z) return ("name is: {y}, guess is: {x}", new_offset) }
mitt_romney_12 commented on Moving Beyond Type Systems vhyrro.github.io/posts/ef... · Posted by u/flexagoon
Seems like you could solve that by endlessly buffering stdin? Then you'd have to keep passing higher and higher offsets to read from, and old offsets would simply return their original, old values.
What happens if you do:
x = read_guess(); y = io.read_int("what's your name: "); z = read_guess();
How would your system ensure x and z are the same?
mitt_romney_12 commented on Moving Beyond Type Systems vhyrro.github.io/posts/ef... · Posted by u/flexagoon
Effect systems have always felt to me like the functional programming community re-inventing dependency injection, but at the type level.
At the term level, you could just let your function have a function as a parameter `read_file: IO -> String`, vs. annotating it with some kind of type-level "filesystem effect". And the former is a lot more flexible over time.
This is an interesting approach but it has some issues with more more advanced effects. For example if you have a function that uses mutable state you would need to have the state both as an input and an output (for the original and the updated state) `update_mut: State -> String -> State` this isn't very economical as is probably worse than just `update_mut: String -> State ()`. If you commit to just having the parameters act as "markers" that don't actually relate to the implementation then you can get away with `update_mut: State -> String -> ()` but then you use one of the big benefits of effect systems which is that you can change the way effects work and have multiple different implementations.
mitt_romney_12 commented on Algebraic Data Types for C99 github.com/Hirrolot/datat... · Posted by u/bondant
In programming language design, we tend to distinguish between global and local analysis. While type checking and elaboration is an example of global analysis, desugaring is inherently local to some piece of code. Therefore, "power" or "expressiveness" usually mean that something cannot be syntactically "expanded"; e.g., while type classes elaborate into explicit dictionaries, they still require information from the type checker, and therefore considered a "real" feature of a programming language. On the other hand, nested pattern matching can be formulated as local syntax transformation, and therefore it doesn't bring anything fundamentally new to the type system or dynamic semantics.
There's also a great talk on the matter [1], if somebody is interested in formalities.
You're approaching this from a PL design standpoint where the distinction is important, but from a user perspective it doesn't matter if it's just "syntax sugar" or if it's a super complicated to implement all that matters is whether the feature is available or not.
mitt_romney_12 commented on Coroutines and effects without.boats/blog/corout... · Posted by u/todsacerdoti
There’s a trade off - was the mistake here or there? The type checker cannot know. But for those few cases you can add an annotation. Then the situation is, in the worst case, as good as when types are mandatory.
> the situation is, in the worst case, as good as when types are mandatory
The worst case is actually worse than when types are mandatory, since you can get an error in the wrong place. For example, if a function has the wrong type inferred then you get an error when you use it even though the actual location of the error is at the declaration site. Type inference is good but there should be some places (ex. function declarations) where annotations are required.
mitt_romney_12 commented on Coroutines and effects without.boats/blog/corout... · Posted by u/todsacerdoti
I'm assuming your language has types which don't have default values because default values for every type are a billion dollar mistake that no modern language should have.
I'm assuming `timeout_return_value` would be a user provided value that serves as the default. But most effect systems also support a `return` effect that lets change the return type of a function [1]. So you could make it return `Just<result>` when it succeeds or `Nothing` when it hits the timeout.
[1] https://koka-lang.github.io/koka/doc/book.html#sec-return
mitt_romney_12 commented on Bun, JavaScript, and TCO onsclom.net/posts/javascr... · Posted by u/tosh
Not to be a dog in the fight but…
How is:
const count = (amount: number) => (amount > 0 ? [...count(amount - 1), amount] : []);
The for loop example above, while simple, is easily understood. A junior engineer could fix it. Is it faster? No. Is it easier to understand? Yes. I like the final example as well.
Look, I’m all for being clever when cleverness is needed but some of you JS/TS folks take it to the extreme. I want to be able to read my codebase, not perform archaeological studies. I have the same issue with Rust syntax as well in places.
I will praise the article on this though, optimizations do matter and having something execute orders faster will improve your overall experience. It doesn’t have to be cuneiform. If you must be clever, wrap it in an abstraction that is well documented because you don’t live forever and neither will your code, make it easy(ier) on the next person. While you can nest a recursive function in a tertiary statement coro, don’t. Fire is cool but also burns.
Btw, bun is blazingly fast. I look forward to more.
If you replace the ternary with an if then it's easy to understand for anyone who knows what ... means (which imo every JS developer should know)
const count = (amount: number) => {
if (amount > 0) {
return [...count(amount - 1), amount]
} else {
return []
};
}mitt_romney_12 commented on VanJS – A no-JSX framework based on vanilla JavaScript vanjs.org/... · Posted by u/ms7892
^^^ Apples to oranges:
<DoStuff args={...}><DoMoreStuff args={...}> <DoEvenMoreStuff args={...}/> </DoMoreStuff> </DoStuff>
DoStuff(DoMoreStuff(DoEvenMoreStuff()))
Also with 2 you can do
const todo = DoMoreStuff(DoEvenMoreStuff());
DoStuff(todo);
With JSX you can do
const todo = <DoMoreStuff args={...}><DoEvenMoreStuff args={...}/></DoMoreStuff>;
<DoStuff args={...}>{todo}</DoStuff>mitt_romney_12 commented on The median return of 2022's SPAC mergers: -82% pranshum.yarn.tech/24dade... · Posted by u/pranshum
SPACs, in theory, democratized access to late-stage private markets, aiming to give retail investors an early seat at the table. but like many financial innovations, they're tools that can be wielded wisely or poorly. the high failure rate suggests a misalignment of incentives: founders and sponsors capture immediate liquidity, while long-term outcomes get obfuscated by the structure.
I once had a chat with a founder who merged his startup with a SPAC. He mentioned that the allure wasn't just the capital but the perceived simplicity of the process, compared to a traditional IPO. But looking back, he felt that the rigorous scrutiny of the traditional path might have forced his team to address underlying business challenges they'd later face.
in any event the real question here isn’t whether SPACs as a vehicle are intrinsically flawed, but if the market’s appetite for risk, combined with the allure of quick liquidity, blinded many to fundamentals during the 2020 bubble. With any financial innovation, there's often a cycle: initial excitement, over-extension, contraction, and then matured understanding. Perhaps we're in the contraction phase for spacs, but they might still find a place in a more judicious market
> With any financial innovation, there's often a cycle: initial excitement, over-extension, contraction, and then matured understanding
I'm a little more cynical, I think the cycle is: a new financial invention comes out, greed causes people to people to pump money into it, eventually the bubble pops or regulators step in. We've seen it time and time again: the dot com bubble, the subprime mortgage bubble, SPACs, and now/soon (IMO) with PE. My question is how many times this has to happen before we stop viewing it as an isolated with specific product and start to see it as a system issue with our financial system.