tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
In my case, only part of the program is recompiled and re-evaluated. The rest is located in a "committed" frozen area. Users can try new changes and throw them freely. The editor performs an evaluation/rollback on every keystroke, ensuring no accumulated or unintended changes to the stated were made during editing. When the user is satisfied and hit run, a long-term snapshot is created and the source code snippet is moving to the frozen area. Thats critical because the edit also rollback the file positions and streams.
tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
Nice, the main problem is a broken state. I use immutability at the language level to prevent disaster code changes. So, the program during live coding is literally unkillable, and you can jump back to the saved checkpoints without restarts.
tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
The tool uses a Forth-like language with immutable data structures and persistent memory snapshots. It also uses Clojure style meta-data and compile-time meta-programming. I have no luck convincing people that a language without curly brackets is useful.
tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
Maybe this is some kind of art that doesn't need to be useful.
tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
I wish to have the skills to explain my work as well as Bret Victor does. Editing, reverting, and committing parts of a running program feel alien to users.
tov_objorkin
|
3 months ago
|
on: The Future of Programming (2013) [video]
I was greatly inspired by his work. After getting enough skills, I even built my own IDE with live coding and time traveling.
Its practical use is questionable, and it seems like nobody is really interested in such tools.
Playground: https://anykey111.github.io
Images: https://github.com/anykey111/xehw
tov_objorkin
|
3 months ago
|
on: Designing a Language (2017)
Bold plus, making PLs is a lifestyle, not a business. Most PLs clones each other and absorb features. The only difference is QOL and tooling. Users expect to have a full set of batteries, an IDE/LSP, jobs, OOP style, and minimal effort to learn. Being popular contradicts with the idea of pushing the boundaries and shifting paradigms.
tov_objorkin
|
4 months ago
|
on: Forth – Is it still relevant?
Disagree, there is no types in Forth, only cells. User is acting as a compiler. Comparing to C, imagine that every keyword like for/while/break is implemented as a macros using setjmp/longjmp. And this is a strong part of the language, flexibility but without any guarantees.
tov_objorkin
|
4 months ago
|
on: Forth – Is it still relevant?
Factoring is good way to reduce the complexity but writing math is painfull experience.
To be fair, the infix version of Forth exists as an extension library.
tov_objorkin
|
4 months ago
|
on: Forth – Is it still relevant?
Forth is pretty lowlevel, i don't think it can compete with the highlevel languages. Postfix notation and stack juggling is just boring.
tov_objorkin
|
2 years ago
|
on: QtWayland 6.6 Brings Robustness Through Compositor Handoffs
One very stupid reason is the Qt itself, graphics application can't live without the QScreen instance. If user unplug every screen from the system, in order to prevent crash qt create the fake screen and hang in the headless state.
tov_objorkin
|
2 years ago
|
on: Compiling Rust for .NET, using only tea and stubbornness
tov_objorkin
|
3 years ago
|
on: Nuklear – A single-header ANSI C immediate mode cross-platform GUI library
I have backend for the Hisilicon SoC from 2016, its about 1500 lines of C code, few calls to 2D API and copypasta of the triangle rasterizer. Dunno about modern version requirements.
tov_objorkin
|
3 years ago
|
on: Little languages are the future of programming
Borrow checker is fine. But from the library writer perspective its pain and take enormous amount of time to make it sound.
One does not simple checkout "nom" and test thing in few minutes.
tov_objorkin
|
3 years ago
|
on: Little languages are the future of programming
Oh, please, making reasonable good DSL might take a month or even years.
Also wrestling with parser and borrow checker not an easy task for average user.
tov_objorkin
|
6 years ago
|
on: Show HN: To fight quarantine boredom I build a site to watch movies with friends
We're social animals, this is hardcoded part of our brain.
Managing solitude require training as anything else.
tov_objorkin
|
6 years ago
|
on: Speeding Up the Rust Compiler
You're technically right, i mean if user aim for durable code then using unwrap is not desired behavior most of the time.
For example pointer deference in C is implicit operation.
In Rust user must choose explicitly how to handle Option/Result.
Even if using unwrap not so harmful as using unsafe and didn't violate rules this is our deliberate choose to break "end-user safety".
tov_objorkin
|
6 years ago
|
on: Speeding Up the Rust Compiler
unwrap() or expect() unconditionally smash program execution in case of error.
Properly written program should handle such errors or use unwrap_or_* as fallback.
The point is that unwrap/unsafe is breaking safety rules, user writing one know what hes doing or just don't bothering.
tov_objorkin
|
6 years ago
|
on: How Discord achieves native iOS performance with React Native
About JS, i made wrong assumption that we entered v8 era and my number crunching code should work reasonable fast everywhere.
tov_objorkin
|
6 years ago
|
on: How Discord achieves native iOS performance with React Native
About five years ago i have a dream, that i can abandon all this peasant C/C++ development and jump into mono/xamarin train.
As a main product we have Linux ARM/MIPS karaoke machine with optional remote control via desktop/mobile apps.
The idea was to use same code every where.
- Tooling for Linux was horrible, like really!
- Alien mobile UI look and feel
- One can not simple build mobile app for desktop.
- New shiny search engine prototype doesn't fit into low tier Phone RAM.
- Mono Hello world application on MIPS device with 128RAM uses about 28 mb of RAM.
- 400 MHz cpu have really hard times with GC, nogo for soft-realtime.
- No seamless integration with native code, using libs like ffmpeg is crazy hard.
- F# was 2nd citizen in that time!
Now things changed, but still imho Linux is not a good choose for .net, also MS force you to use Azure/Cloud/etc infrastructure.
