slacknatcher12
Joined 4 years ago
Joined 4 years ago
C is in an odd position right now to argue it is how the machine is really working. Computers are more complicated since bigger caches entered the picture. Hell I do not think even ASM is a good approximation on how machine really work given the data dependencies will make stuff being processed in parallel instead of sequentially.
What you could argue is that C is the archetype for an imperative language procedural language with a clean mapping to ASM. That is different than how the machine works. Simpler architecture have less distance between their ASM and what is really hapenning.
https://github.com/Kleidukos/ghcup-gtk/blob/d384e89dd48b4065...
for an example. That program is a UI for the standard haskell installer.
1. Use a native widget system such as GTK (I evaluated Qt too)
2. Wrap widgets into a component datatype that is aware on how to update the widget when the props/model changes.
3. Define a dispatch closure that is passed to widget that accepts messages. Actions on the widgets should use this instead of mutating a reference.
4. That dispatch closure is component aware and it will call the update function on all the widgets.
There are some extra complications for long running computations but the model is a good base to build on. I wish the best to the relm team, most likely I will use them when programminmg in rust.
Remote: Yes
Willing to relocate: Yes
Technologies: Scala, TypeScript, Haskell, C, Python
Résumé/CV: https://drive.google.com/file/d/1gybGW79IH0FGknYaGL2Yr6nhwMK... Email: [email protected]
Mathematician (optimization) turned software engineer, 5+ of experience. I believe that with good mathematical models we can ship better code and products. I have good experiences doing front-end development but I am a better backend developer. I have a slight bias to functional programming. I pride myself on shipping products that our users have loved. If you work on a domain with good data, I would love to take a look.
Remote: Yes
Willing to relocate: Yes
Technologies: Scala, TypeScript, Haskell, C, Python
Résumé/CV: https://drive.google.com/file/d/1vQGecOf8YCm4Tj4vZbTAJKaD5S2...
Email: [email protected]
Mathematician (optimization) turned software engineer, 5+ of experience. I believe that with good mathematical models we can ship better code and products. I have good experiences doing front-end development but I am a better backend developer. I have a slight bias to functional programming. I pride myself on shipping products that our users have loved. If you work on a domain with good data, I would love to take a look.
on a commercial setting there is more pressure to deliver code then to review it. combine it with the lack of our benevolent dictator for life (that has been on the project the world life cycle, not just recently), there is no one with power to actually say no to changes.
language geeks are novelty seekers. they will use every feature of their language . stronger languages have more features to abuse. so on a commercial setting you will have all the features being used without much thought an architectural design that says you that no, we shouldn't do that.
that's also why I think projects with benevolent dictators for life on the open source ward don't fall these in paths even though they use languages that are stronger.
you could restrict yourself to use languages that have only one way to be used, so python as it was originally. or use a language little abstraction power. but you will suffer in other ways. as abstraction power is genuinely useful. accidental complexity has a way of getting in by expressive means or by social means.
I had testicular cancer in 2006 in Chile. I was a teenager so I went with the public system (AUGE back then). My parents friends were giving the condolences for my soon to occur death. The doctors had a laugh as in the last 10 years (by then) my chances of dying of it became basically nil.
Last year we hired a new guy at $JOB that 1 week after being hired was diagnosed with testicular cancer too. He really thought he was gonna die. He was at stage 4 (which is a highly zone specific metric). Last time I saw him he is still coding and more bald. It was more difficult to sort payments than the treatment as he is in the US.
This is off-repeated, but has two interpretations. If you mean performance as in number of steps needed to reduce an expression, lazy evaluation is superior to strict evaluation. If you mean the indirection needed to access a thunk, well someone -- either the producer (strict) or the consumer (lazy) -- had to do that anyways. If GHC can determine that the demand for the value is strict, it won't generate the thunk in the first place. Instead it will provide a specialize calling convention via the worker/wrapper transform, which is standard. On the un-optimized case we still have dynamic pointer tagging (which is a transgression on the T of the STG machine) which serves as a tag to check whether we are dealing with a value or a thunk quickly. So if by non local performance you mean the indirection, modern GHC shows that is not true.
If you means that space leaks are a non-local property and they affect performance, well you are sort that right. But as with all programming, we have defensive patterns against that.
There are 2 types of space leaks: liveness leaks and strictness leaks. Only the first one are a non-local property, ie the appear as a consequence of the composition of different code pieces. But given the default purity of Haskell, those can only appear on long lived data references with are syntactically marked by:
- IORef, MVars, TVars
- get/put pairs over a state environment
So what you do is to specify in the types that values stored on those environments are to be evaluated before being stored, so references don't leak. I speak about this on this
https://epicandmonicisnotiso.blogspot.com/2023/04/how-to-avo...
and how to specify the a specific evaluation level on the types at here
https://epicandmonicisnotiso.blogspot.com/2023/04/presenting...
although that library has changed a lot to enforce the invariants.
I just want to add that this post makes more sense if it is read as a continuation of the argument made on here <https://epicandmonicisnotiso.blogspot.com/2023/03/an-apologi...> which had comments on HN on here <https://news.ycombinator.com/item?id=35305546>
BTW: I am open for hiring :^)
- Remote: Yes
- Willing to relocate: Yes
- Technologies: Haskell, Scala, Rust, Nix, Postgresql, C (not C++), Linux, typescript.
- Résumé/CV: https://drive.google.com/file/d/1vQGecOf8YCm4Tj4vZbTAJKaD5S2...
- Email: [email protected]
- Github: https://github.com/RubenAstudillo
I am a (applied) mathematician turned software engineer. I have worked at backend services and iOS apps. I have some side projects involving micro controllers and kernel programming. Last job was on a haskell shop, I would like to keep using functional programming at work if possible. Problem domains with lots of data analysis are great as I can use my math background.