This is definitely a niche space but I see clear use for large, portable and configurable c codebases (e.g. Linux kernel, FreeRTOS) for providing better visibility into the configuration system.
222 karma · joined December 2, 2019
This is definitely a niche space but I see clear use for large, portable and configurable c codebases (e.g. Linux kernel, FreeRTOS) for providing better visibility into the configuration system.
For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_... )
Readability, composability and elegance in programming are always a reaction to trauma caused by the shortcomings of some previous system. Therefore I think it is not possible to teach new programmers to write it.
I think this trauma is the most fundamental force in organizational coding standards as well as programming language design.
My conclusion for now is that the choice to use C coroutines is best left to the library user. For example: Mongoose (https://github.com/cesanta/mongoose) uses event callbacks to deal with asynchronousness. It is much more pleasant to wrap a library like this in whatever thread/task primitives your system has rather than try to port the mythical cross-platform C couroutine or worse, std::thread.
Good to know.
[1] https://djyresearch.com/2021/03/30/details-bilibili-and-bull...
Agreed. I've used jinja2 quite a bit for templating C with structured data. It is very effective. Ned writes that he also considered templating engines but was not satisfied when trying to implement more complex code generation inline. I feel like I understand Ned's thought process here but I strongly disagree with his conclusion unless it's for personal use only. Cog is subject to the lisp curse.
Dads may or may not know more about plasma than an LLM. In any case this kid can now ask both Dad and Robot Dad and compare the answers. That's pretty cool.
You can read more about it here:
https://baike.baidu.com/item/%E7%BD%91%E7%BB%9C%E6%B0%B4%E5%...
Online water scouts are hired online writers who publish specific information about specific content in the Internet. They are usually active in e-commerce websites, forums, microblogs and other social networking platforms. They influence normal users by disguising themselves as ordinary Internet users or consumers and by posting, replying and spreading blog posts.
> The current situation is that Western water forces, through insidious and poisonous means such as the Internet, have created a very dangerous atmosphere of public opinion and incited the people to rebellion. If we are deceived and held hostage by these rumors, what China will end up with will only be a disaster. We have to believe that the country, more than anyone else, wants an early end to the epidemic, and more than anyone else, wants an early end to this costly and socially expensive epidemic prevention activity, so that society can return to normal and the economy can recover as soon as possible. We believe that the Party and the government will be able to lead the people of China to work together to overcome the epidemic! China will win! [fist][fist][fist]
> 当前形势是西方水军通过网络等阴险毒辣的方式,已经营造了一个非常危险的舆论氛围,煽动民众叛乱,如果我们被这些流言所蒙骗和裹挟,最后中国迎来的只会是灾难。我们要相信,国家比任何人都希望疫情早日结束,也比任何人都希望早日结束这种耗资巨大、社会成本巨大的防疫活动,让社会恢复正常,经济早日复苏。相信党和政府,定能领导全国人民,同心协力,战胜疫情!中国必胜![拳头][拳头][拳头]
- It's a money-making scam by the COVID test manufacturers
- It's a money-making scam by the temporary quarantine center manufacturers
- It's a failure of bureaucracy ”层层加码”
- It's a ploy to increase the depth of state surveillance
- It's a ploy to lock people at home and increase the birth rate
- It's a ploy to keep the poor poor to ensure that they keep working hard
- It's to mitigate war with the United States. Apparently the Geneva convention has a clause against going to war with a nation stricken by a pandemic.
The root of the worrying pattern is that you and your team are not aligned on what Technical Debt is. Do you have a design/code review process? Do you have a coding standard? (I think these are prerequisites to alignment)
Using the unfamiliar library example, there could be a review process that happens before the rewrite that considers at least the following:
- code life: is this throwaway code or will it be used for the foreseeable future, have good enough documentation and tests to survive team turnover?
- team knowledge: what technologies are familiar/unfamiliar? What technologies should we all be learning?
- alternatives: what existing libraries are available? How well do they meet our needs?
Cautionary Anecdote: I once joined a startup. I remember the last bulleted line in the job description was "Preferred: Knowledge of functional programming languages such as Scheme". The interview process was straight C++ and no one mentioned a word about functional programming. After a couple weeks of code sifting and it became clear that a former team lead who'd recently been let go was a hardcore Scheme guy. He built and maintained a chunk of the build infrastructure which by the time I arrived had been obsoleted by a Python tool. No one else at the company understood or wanted to learn Scheme. (Nothing against Scheme BTW). The desposed team lead failed to bring themself and their team into alignment. That they were removed rather than leaving on their own indicates that they either failed to recognize the problem in time or recognized it and chose to ignore it.
You must be clear on the existing skills of your team members and realistic about what they are capable of and can be motivated to learn.
> 自主可控、纯中文国内社区
> Independent and controllable, pure Chinese domestic community
Doing software projects for domestic and foreign users is extra work, and the community seems to fragment along language lines. For example: https://www.esp32.com/index.php
I guess a 纯中文国内社区 is one way to solve this, but then why post on hacker news? This seems contradictory.
See this example: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_...
It's working.
https://foreignpolicy.com/2016/06/03/china-explained-sixth-t...
Great essay. The simulations sure make this point hit hard. I feel the author's jadedness coming out here.
Should one feel like a small colored dot encircled by immune grey, it is essential to maintain a belief in agency: believing oneself capable of networking, relocating, and modifying the surroundings.
There are a few versions of the blob floating around the internet and its features are anything but well-documented. Example:
https://stackoverflow.com/questions/66324744/setting-initial...
Sticking to the spirit of the question, I will categorize the tools mentioned in the comments. They solve very different problems, so the "ideal tool" absolutely depends on the task at hand. I think this rough categorization can help to select the right tool for the job.
The first class of tools are drawing tools. These tools aim to aid design and communication. plantUML http://www.plantuml.com/ is best suited to manual use. I use plantUML when sketching out designs. It's great for thinking about and communicating state machines, system architecture, and server-client or multiprocess interactions. The problems solved by plantUML can also be solved by general GUI diagramming software like Visio or LibreOffice Draw. I'll not dawdle on the pros and cons.
A second class of tools are static analysis tools. These are more of a microscope than they are a sketch pad. They operate on existing code and the user input comes as filters or options to get the desired level of detail. The examples here all produce graphviz .dot files:
bazel query for dependency graphs - https://bazel.build/docs/query-how-to
Doxygen C call graphs and struct inheritance graphs - https://www.doxygen.nl/manual/diagrams.html
radare2 generates call graphs from an .elf file - https://reverseengineering.stackexchange.com/a/9120
A DBC visualizer (CAN bus protocol specification file) - https://github.com/driftregion/dbcview (mine)
These tools are great not only for probing the depths of an unfamiliar codebase but also because they give insights to people already familiar with that codebase. For example: statically generated callgraphs showed that some debugging hooks had been left in. They've also shown duplicate code paths.
A third class of tools mentioned in the comments are dynamic analysis tools: profilers, tracers, debuggers. These are the oscilloscopes and signal analyzers of software engineering. These seem to be outside OP's query.
> Why isn't diagram generation automated as part of the build process (UML or otherwise)?
The output of class 1 and 2 tools is used in builds. Doxygen supports plantUML (class 1) and callgraph generation (class 2). Class 1 is obviously manual, and class 2 is also manual for reasons that others have mentioned here: namely adjusting to get the right level of detail. The text output of class 3 tools is often used in CI as a pass-fail indicator.
> Why aren't code visualization tools more popular? The options out there seem outdated.
My anecdotal experience is that these tools are specialized and therefore have a small audience. They solve problems related to design and analysis of software which is a small part of "real world" (sorry) software development.
edit:formatting