henryluo

Yes, I thought of this issue when I name it Lambda. But I like the name 'Lambda'. Once get over the initial stage, Lambda will be easy for people to remember.

Quint is an interesting lang, and the concept of 'executable spec' is definitely the direction to go in the age of AI vibe coding.

And the language, Lambda, that I designed and implemented has many similar characteristics: https://github.com/henry-luo/lambda

thanks.

As for the performance, I'm standing on the shoulder of great tools like MIR JIT compiler.

Lambda's PDF support is still very limited at moment. I do plan to enhance it in next release.

Glad to hear that. Note that the language is still being developed, and there're bugs here and there. So bear with those bugs. But it should be fun to try it out.

Hope it will change the way people work with data and documents.

While Lambda still has a pretty static GUI at the moment. My plan is to build it into a fully interactive, editable UI on all kinds of document data.

As for the '<' and '>' to open and close an element, there are two potential kinds of syntax design. Option 1 is to use some explicit delimiters. Mark 1.0 has settled on '<' and '>'. Mark 0.11 was using '{' and '}', which I felt confusing with map. So I changed to '<' and '>', to make it consistent with HTML/JSX and XML, which most developers are already used to. Option 2 is to use indentation to delimit the enclosed child content, like in Python and YAML.

Option 2 looks cleaner for configuration kind of usage. However, Mark is designed to be embedded in a scripting language, and used beyond just configuration files. Unless the scripting language uses indentation as delimiter, like Python, option 2 will not work.

Personally, I prefer C/Java/JS family of languages that has insignificant whitespace. So Mark is designed to use explicit delimiters '<' and '>' to enclose an element.

Hope that explains one of the most important syntax designs of Mark.

A new notation by itself won't be useful. It's the tool stack, the eco system around it that matters. That's why I'm building beyond that the format itself. I'm building the schema, the validator, the scripting and query language around it.

Here's the XKCD 927 post from last beta release: https://news.ycombinator.com/item?id=16308803

Yes, it's a must! Have that posted in the 0.11 beta release as well. :-)

Glad you like it. I have bigger plan for what's currently released. My next goal is to unify the schema of all those data formats, like JSON, XML, HTML, etc. And make the new Mark Schema able to validate all those data formats.

Glad to see your comment. Not sure I get you right. I also do not like many data notations and formats floating around. I hope there's one notation that can unify all the data that I'm concerned with. That's why I created Mark.

"When the way of code is abandoned, doctrines of ‘best practices’ and ‘standards’ appear. When intuition is dismissed, cleverness and pretense follow. When harmony is unnoticed, rules and processes multiply. When software fails, zealous testers arise."

Do you agree to Linus Torvalds that “Visual Basic did more for programming than Object-Oriented Languages did”?

Fake traffic, and spam everywhere. A constant war for all public content and services.

Nice to see different architecture styles compared side-by-side in one concise table.

A lightweight 2D graphics library for rendering texts, geometries, and images with high-performance APIs that work across various platforms. Its main objective is to offer a compelling alternative to the Skia graphics library while maintaining a much smaller binary size.

It will work out to some extent at the beginning, but will encounter the Law of Diminishing Returns, and will saturate and flat out eventually.

The dream of AI is the same dream of free money, free content, free everything!

Traffic from Hacker News, I guess. :-)

Very wordy article but interesting point about how cloud is considerably more expensive than on-prem at a large enough scale.

I still thinks C is a simple and beautiful language. However, C's standard libraries are really out-dated and error prone.

seems like a pushing site

I sympathize and resonate with the author.

While for me, the JS language features are still manageable. What has outgrown me are the layers upon layers of abstractions used in modern JS app, like React/Redux/... We no longer have a straightforward, plain JS app. To understand the code, we have to 'see through' the thick layers of frameworkds/middleware.

Modern JS app is becoming as ugly as J2EE last time used to be.

I've come up with a new notation Mark (http://marknotation.org/), to address some of issues faced with JSON and XML.

It keeps the simplicity of JSON, and is able to support mixed content at the same time.

At the moment, it leaves out namespace to the application.

Your sample in Mark would look like:

  {html
    {head
      {concept tag:computer-game guid:"c1a3e0cb-5872-4e5a-8dce-b8afc00772db"}
      {concept attribute:year-published guid:"ba073188-8bd6-47a7-9065-eb55c4a8b908"}
    }
    {body
      {computer-game year-published:1993 "Doom"}
    }
  }

There's also Mark Notation (http://marknotation.org/), which is also a tree notation. Less verbose than XML and JSON.

  {World
    {Asia
      {China '1409517397'}
      {India '1339180127'}
      {Indonesia '263991379'}
    }
  }

Yes, Solid is something to looking forward to.

Many years ago, we face the vendor lock-in problem from the software giants, due to proprietary data formats. Thanks to Tim, W3C, XML and open source community, that is less of a problem today.

But now we face the problem of vendor lock-in, not due to proprietary formats, but due to cloud-service lock-in. With all the software giants, Microsoft, Google, Facebook, Amazon, ... offering their services primarily as cloud services, this cloud lock-in issue is going to become more severe in years to come.

It's a new war the software industry needs to fight. It cannot be addressed just by one person, one project, one organization. It needs collaboration from the entire community.

Yes, Solid is something to looking forward to.

Many years ago, we face the vendor lock-in problem from the software giants, due to proprietary data formats. Thanks to Berners Lee, W3C, XML and open source community, that is less of a problem today.

But now we face the problem of vendor lock-in, not due to proprietary formats, but due to cloud-service lock-in. With all the software giants, Microsoft, Google, Facebook, Amazon, ... offering their services primarily as cloud services, this cloud lock-in issue is going to become more severe in years to come.

It's a new war the software industry needs to fight. It cannot be addressed just by one person, one project, one organization. It needs collaboration from the entire community.

"In September 2008, Stack Overflow's public beta went live. Today it's the the largest online community for programmers to learn, share their knowledge and build their careers. Today, the site is visited by over 50 million programmers a month; in ten years 9.3 million users have provided 25 million answers to 16 million questions. Watch Stack Overflow employees and users walk down memory lane and say thank you."