hzhou321

One is a boss's view, looking for an AI to replace his employees someday. I think that is a dead end. It is just getting better to become a sophisticate, increasingly impressive but won't work.

One is the worker's view, looking at AI to be a powerful tool that can leverage one's productivity. I think that is looking promising.

I don't really care for the chat bot to give me accurate sources. I care about an AI that can provide likely places to look for sources and I'll build the tool chain to lookup and verify the sources.

hzhou321

3년 전discuss

> To illustrate, Rust macros are basically that. They have a substantially different syntax to normal Rust code that make it very difficult to quickly grok what is going on. It's a net negative IMO, not a positive.

Yeah, more like a syntax extension than macro. But I am saying that you need both. Some time you need powerful macro ability to extend the language. Sometime you just need templating to achieve the expressiveness. With LISP, I get it that you are programming all the time, never templating, right? But I guess you only appreciate templating when you use your macro system as a general purpose system . The benefit of general purpose macro systems is you only learn one tool for all languages, rather than re-learn the individual wheels. And when you judge a language, you no longer bothered by its syntactic warts because you can always fix the expressive part with your macro-layer.

hzhou321

3년 전discuss

M4 only do token-level macros or inline macros. M4 macros are identifier that can't be distinguished from underlying language. M4 macros does not have scopes. M4 does not have context level macros. M4 does not have full programmable ability to extend syntax.

I can define any macro lisp can define, just not with LISP syntax. I do not have a full AST view of the code, due to the its generality that it does not marry to any specific underlying language. But I can have extensions that is tailored to specific language and do understand the syntax. For example, the C extension can check existing functions and inject C functions. MyDef always can query and obtain the entire view of the program, and it is up to the effort in writing extensions to which degree we want macro layer to be able to parse. Embedding a AST parser for a local code block is not that difficult.

It's like the innerHTML thing, for me, I always find the text layer (as string) is more intuitive for me to manipulate than an AST tree. If needed, make an ad-hoc parser in Perl is often simple and sufficient, for me at least.

hzhou321

3년 전discuss

In another word, it (to have runtime macro expansion) is a side effect, a compromise, a wart, rather than a design goal, right?

hzhou321

3년 전discuss

> I think a general purpose macro language is only as useful as the average code-gen/templating language. It's just string manipulation, which can be harder to reason about than true metaprogramming ...

I would like you to reconsider. Predicting a program output is hard. So in order to comprehend a macro programed as code, one need run the macro in their head to predict its output, then they need comprehend that output in order to understand the code. I think that is unreasonable expectation. That's why reasonable usage of meta-programming is close to templating where programmer can reason with the generated code directly from the template. For more higher-powered macros, I argue no one will be able to reason with two-layers at the same time. So what happens is for the programmer to put on his macro hat to comprehend the macro, then simply use a good "vacabulary" (macro name) to encode his comprehension. And when he put his application programming hat, he takes the macro by an ambiguous understanding, as a vocabulary, or some one may call it as a syntax extension. Because we need put on two hats at different time, we don't need homoiconicity to make the two hats to look the same.

hzhou321

3년 전discuss

> That being said, I think homoiconicity is actually a useful feature, but runtime macro expansion is the dangerous part.

Practically, why would you ever want a runtime macro expansion?

hzhou321

3년 전discuss

LISP has been singing homoiconicity as its feature. I lately start to think homoiconicity is really a wart. The macros are a system to program the code, while the code is a system to program the application. They are two different cognition tasks and making them nearly indistinguishable is not ideal.

LISP has a full-featured macro system, thus hands down beats many languages that only possess handicapped macro system or no macro system at all. It uses the same/similar language to achieve it is mere accidental. In fact, I think LISP is an under-powered programming language due to its crudeness. But it's unconstrained macro system allows it compensate the programming part to certain degree. As a result, it is not a popular language and it will never be, but it is sufficiently unique and also extremely simple that it will never die.

What if, we have a standalone general-purpose macro system that can be used with any programming languages, with two syntax layer that programmers can put on different hat to work on either? That's essentially how I designed MyDef. MyDef supports two forms of macros. Inline macros are using `$(name:param)` syntax. Block macros are supported using `$call blockmacroname, params`. Both are syntactically simple to grasp and distinct from hosting languages that programmers can put on different hats to comprehend. The basic macros are just text substitution, but both inline macros and block macros can be extended with (currently my choice) Perl to achieve unconstrained goals. The extension layer can access the context before or after, can set up context for code within or outside, thus achieve what lisp can but using Perl. We can extend the macros using Python or any other language as well, but it is a matter of the extent to access the macro system internals.

Inline macros are scoped, and block macros can define context. These are the two features that I find missing in most macros systems that I can't live without today. Here is an example:

    $(set:A=global scope)
    &call open_context
        print $(A)
    print $(A)

    subcode: open_context
        set-up-context
        $(set:A=inside context)
        BLOCK # placeholder for user code
        destroy-context

hzhou321

3년 전discuss

The ban is not having an issue between China and US. US can do whatever to China, and only need balance potential retaliation. There is no moral debate between countries, just power play.

The ban is an issue between US government/politicians and US people. There are some nominal moral contract between the government and people, and the ban need to be justified and satisfied by people's moral belief, such as open internet. Without sufficient moral justification, people's trust against the government is at risk.

hzhou321

4년 전discuss

Since you are already familiar with other languages, I suggest just pick a tool that you use daily that is open source in C, and start hacking it.

hzhou321

4년 전discuss

Some billionaires grow integrity at some point since every thing else is just money. Some billionaires never.

hzhou321

4년 전discuss

> C specification says a program is ill-formed if any UB happens. So yes, the spec does say that compilers are allowed to assume UB doesn't happen.

I disagree on the logic from "ill-formed" to "assume it doesn't happen".

> I think you're conflating "unspecified behavior" and "undefined behavior" - the two have different meanings in the spec.

I admit I don't differentiate those two words. I think they are just word-play.

hzhou321

4년 전discuss

> Indeed. UB in C doesn't mean "and then the program goes off the rails", it means that the entire program execution was meaningless, and no part of the toolchain is obligated to give any guarantees whatsoever if the program is ever executed, from the very first instruction.

This is the greatest sin modern compiler folks committed to abuse C. C as the language never says the compiler can change the code arbitrarily due to an UB statement. It is undefined. Most UB code in C, while not fully defined, has an obvious part of semantics that every one understands. For example, an integer overflow, while not defined on what should be the final value, it is understood that it is an operation of updating a value. It is definitely not, e.g., an assertion on the operand because UB can't happen.

Think about our natural language, which is full of undefined sentences. For example, "I'll lasso the moon for you". A compiler, which is a listener's brain, may not fully understand the sentence and it is perfectly fine to ignore the sentence. But if we interpret an undefined sentence as a license to misinterpret the entire conversation, then no one would dare to speak.

As computing goes beyond arithmetic and the program grows in complexity, I personally believe some amount of fuzziness is the key. This current narrow view from the compiler folks (and somehow gets accepted at large) is really, IMO, a setback in the computing evolution.

hzhou321

4년 전discuss

Nice! If the robots can sustain on solar energy, even better.

hzhou321

4년 전discuss

How silly is this.

hzhou321

4년 전discuss

What prevents linux to achieve the same bandwidth?

hzhou321

4년 전discuss

It's not about the amount of time kids takes up in your life. It is about how kids changes your life forever. Your priority in life changes, then your life changes. I guess when kids leave us, we need relearn the life.

hzhou321

4년 전discuss

The `infix` syntax is missing from the major items. Without infix syntax, all languages are just variations of LISP -- I guess that was all the article is about.

hzhou321

4년 전discuss

For those who are interested, checkout MyDef - https://github.com/hzhou/MyDef

hzhou321

4년 전discuss

Yes, I agree! In fact, the break through we needed is to view programming as a human cognitive operation and embrace the text, and treat manipulating text as a main component of coding. For example, I want to code

     foreach item in list_A
         do_something(item)

This text is the native code in the programmer's mind, and we should allow programmer to just do so. Then, in a second layer, the programmer should code up the transformer and translate that to the actual programming language, adding incidental complexity such as specific syntax and internal language representations, so that the lower level compiler can verify and consume and feedback.

The transformer part is super hard if we rely on automatic tools, which is just another version of a compiler. It is super tedious if we rely on human manual work, which is just how today programmers do. But if we view the transformer part as part of programming, where programmer employs tools to mold their program, then it makes sense. The programmer will be able to program the tools to avoid the tedious part but still with full flexibility to mold anyway they desire. It is still programming, but in a meta frame where text is the target.

hzhou321

4년 전discuss

The author's view is very relatable (to me). I am going to bookmark it since it verbalize my feeling so fittingly. I am not sure I am autistic, but I have to be to some extent.

I can see where the essay goes partial. The author focuses on explaining self, but neglect in analyzing why others are having issues understanding the author. And I think I understand the reason -- the author is simply (much) more interested in solving the engineering problems than the political problems. The author probably understand the importance of politics, but simply not interested.

I can relate to that. I don't even think that is a problem. If you are happy focusing on technical problems and want to avoid the political side, so be it. However, I am concerned that the author mentions burnout. If you are having risk of burning out, then apparently there is an issue and the author is stubbornly avoid addressing the issue.

The answer may not be -- you need learn and play politics. It could be -- you need learn to balance yourself. It depends on individuals, but refusing to address it is wrong.

Submissions

Show HN: A CC Wrapper for -finstrument-functions

MyDef, a general preprocessor

MyDef Manual

Perl from scratch

Determinism and Free Will

Why we are different in a crowd

Send More Money

Imperative Parser – Parsing JavaScript in Python

Operator precedence based parsing

Write a calculator parser imperatively

Implementing Hobby Curve

Direct Approach Neural Networks

Vocabulary based programming

Adding a hash table in C

Programming is Natural

What you see is what you think

Programming in MyDef

comments