denis_dolya

The only thing I can say when I saw it is — WOW!

Good afternoon, I liked the game, I especially liked that you created it on your own engine.

But I have a question, are you planning to make apps for these platforms, Is this how the web version will end?

Interesting approach. Rendering LaTeX directly in the terminal lowers friction for math-heavy workflows, especially in REPL environments or when working remotely without GUI support. It’s lightweight and demonstrates clear technical creativity.

On the downside, the terminal was never designed for this use case. Performance, portability, and long-term maintainability are questionable. Existing ecosystems like Jupyter or MathJax already solve this problem in a more standardized way. This makes the project more of a niche tool or proof of concept rather than something broadly adoptable.

Looking at Scar through the eyes of a senior developer the reaction is more curious than dismissive. There is a bit of surprise because in the past system languages were almost always implemented in C and that was considered a mark of seriousness. Now we see an example built on Go and that shows how approaches are shifting. The choice of Go has strengths like simple syntax, fast development cycle, built in support for concurrency, and good infrastructure. At the same time there are compromises like weaker memory control compared to C and some runtime overhead which can be critical for low level languages. Scar looks more like an experimental attempt to propose a new view on language design with emphasis on simplicity, immutability, and optional GC. As an engineer I find the idea interesting but its value can only be judged when real use cases appear and we see how it behaves under production workloads and whether it can compete with Rust or Zig.

Do you plan to publish the source code?

If you need regular Deep Research without relying on a UI the simplest option is to run a model locally or via an API such as HuggingFace or OpenAI Chat API with a Python script that runs on a schedule using schedule or cron. Locally you can use models like Falcon LLaMA or GPT4All wrap them in a function that takes a prompt and returns the result and run it automatically on a server or PC. For a long term solution store the results in a file or database. This gives full control and independence from external interfaces.

It is remarkable how a seemingly simple architectural idea can have such practical impact. The saw-tooth roof demonstrates that straightforward, well-considered design can optimize natural lighting while minimizing complexity in construction and maintenance. Its combination of simplicity and functional efficiency makes it a highly effective solution in both historical industrial contexts and modern sustainable architecture.

Gemini has demonstrated an impressive level of performance, achieving gold at the ICPC World Finals. That said, there are aspects that still require improvement. In particular, the model does not always interpret problem statements correctly and often requires very precise or explicitly structured instructions. This can be inconvenient in practical use, and I hope future versions will implement a more intuitive approach to understanding task descriptions.

I’ve been working with SQL Server from Python on various platforms for several years. The new Microsoft driver looks promising, particularly for constrained environments where configuring ODBC has historically been a source of friction.

For large data transfers — for example, Pandas or Polars DataFrames with millions of rows — performance and reliability are critical. In my experience, fast_executemany in combination with SQLAlchemy helps, but bulk operations via OpenRowSets or BCP are still the most predictable in production, provided the proper permissions are set.

It’s worth noting that even with a new driver, integration complexity often comes from platform differences, TLS/SSL requirements, and corporate IT policies rather than the library itself. For teams looking to simplify workflows, a driver that abstracts these nuances while maintaining control over memory usage and transaction safety would be a strong improvement over rolling your own ODBC setup.

Restricting PNG to a smaller subset is a reasonable idea, and I did consider it. The challenge is that even a limited PNG still requires handling deflate compression and integrity checks, which add complexity to the parser. On many classes of microcontrollers, that creates unnecessary overhead and dependencies. My goal is to design a format that can be fully described on a single page of documentation and implemented from scratch in just a few hours, while remaining flexible enough to extend in the future.

ASTC, ETC, and DXT are indeed efficient formats, especially when hardware support is available. In my case, the target devices are microcontrollers without GPUs and with very limited RAM. A software decoder for these formats would require more resources than are realistically available. That is why I am exploring a simpler format that can be implemented with minimal overhead and predictable performance, even on very constrained hardware.