More or less. It's a perfectly workable approach, but it's the reverse of what practically everyone else does, as well as the reverse of regex notation. Common notations should be common.
6,599 karma · joined October 31, 2013
<!DOCTYPE html example [
<!ENTITY myheader SYSTEM "myheader.html">
]>
....
&myheader;
This doesn't counter subverted source code, that's not what reproduciblrle builds are for.
Stallman's argument at the time was:
"a language for extensions should... be a real programming language, designed for writing and maintaining substantial programs...
The first Emacs used a string-processing language, TECO, which was inadequate. We made it serve, but it kept getting in our way. It made maintenance harder, and it made extensions harder to write...
Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.
Tcl has a peculiar syntax that appeals to hackers because of its simplicity. But Tcl syntax seems strange to most users."
Verified reproducible builds could have countered the xz utils break, SolarWinds Orion subversion, and many others. It's worth doing.
The point of formal verification is to ensure that the software meets certain requirements with near certainty (subject to gamma radiation, tool failure, etc.). If mistakes aren't important, formal verification is a terrible tool. If mistakes matter, then formal verification may be what you need.
What this and other articles show is that doing formal verification by hand is completely impractical. For formal verification to be practical at all, it must be supported by tools that can automate a great deal of it.
The need for automation isn't new in computing. Practically no one writes machine code directly, we write in higher-level languages, or rarely assembly languages, and use automated tools to generate the final code. It's been harder to create practical tools for formal verification, but clearly automation is a minimum requirement.
The Definitive Four Fours Answer Key https://dwheeler.com/fourfours/
So the existence of R is evidence that Lisp's syntax is a serious problem. If a language providing syntactic sugar has a significantly increased adoption rate, that suggests that the bitter pill of your syntax is a problem :-).
Language adoption is a complicated story. Many Lispers won't agree with me anyway. But I do think the poor uptake of Lisp demands an explanation. Its capabilities are strong, so that's not it. Its lack of syntactic sugar is, to me, the obvious primary cause.
The vast majority of software developers do not put up with Lisp syntax. The vast majority of software developers use a different programming language with a much better syntax, and never consider using Lisp for anything serious. For example, for most developers, a programming language is a laughable nonstarter if it cannot use infix notation for basic arithmetic, as that is the standard notation for mathematics worldwide and is taught to everyone.
As evidence, look at TIOBE: https://www.tiobe.com/tiobe-index/ ... you'll see "Lisp" is #26, lower than Classic Visual Basic, Kotlin, Ada, and SAS. Scheme and Clojure aren't even in the top 50, so adding them wouldn't change much. Lisps will never break the top 10 with their current syntax.
There is a reason for Lisp's syntax: it's homoiconic, enabling powerful macros. Lisp macros are incredibly powerful, because you can manipulate programs as data. Other macro systems generally don't hold a candle to Lisp's. The vast majority of "simple syntactic sugar" systems for Lisp lose homoiconicity, ruining Lisps's macros. This was even the problem for the M-expressions created by Lisp's original developer. Most of those syntactic improvements also tend to NOT be backwards-compatible.
There is a solution. I developed curly-infix expressions, SRFI-105 https://srfi.schemers.org/srfi-105/ Curly infix enables infix notation WITHOUT losing homoiconicity or requiring a specific meaning for symbols. On top of that I developed sweet-expressions SRFI-110 https://srfi.schemers.org/srfi-110/ . These are backwards-compatible (easing transition) and homoiconic (so macros keep working). There are no doubt other approaches, too.
In general getting anything accepted and used is hard.
Here's my personal take, though: Almost all programmers abandoned Lisps decades ago, in large part due to its terrible syntax. The few who still use Lisp tend to like its notation (otherwise they wouldn't be using Lisp). Since they like Lisp syntax, they don't see the problem. Cue the "this is fine" cartoon dog in a fire. This means that Lisps will never be seriously considered by most software developers today, due to their user-hostile syntax. Some will learn them, as a fun toy, but not use them seriously.
I think that is a terrible shame. Lisps have a lot going for them. For certain kinds of problems they can be an excellent tool.
I realize most people who seriously use Lisp will disagree with me. That's fine, you're entitled to your own opinion! But as long as Lisp has terrible syntax (according to most developers), it will continue to be relegated to a (relative) backwater. It will continue to be learned, but primarily as an "elegant weapon" from a bygone "civilized age" https://www.explainxkcd.com/wiki/index.php/297:_Lisp_Cycles
Even MIT's 6.001 (Structure and Interpretation of Computer Programs), which once taught powerful concepts using Scheme, has been replaced by a course using Python. Reason: "starting off with python makes an undergraduate’s initial experiences maximally productive in the current environment". Scheme did not help them be maximally productive. See: https://cemerick.com/blog/2009/03/24/why-mit-now-uses-python...
I like Lisp. I don't like Lisp syntax. Since most Lispers don't want to fix Lisp syntax, or don't believe it's a problem, the vast majority of software developers have decided to use a different programming language that has a syntax they prefer to use. The numbers from TIOBE make it clear Lisp isn't a common choice.
You'll no doubt get different views in the comments. :-)
AI is a useful aid to software developers, but it requires developers to know what they're doing. We need developers to know more, not less, so they can review AI-generated code, fix it when it's wrong, etc.
The 6502 was designed to be easily implemented with relatively few transistors. For that it was amazing. There is a reason it was popular! But its CPU registers are only 8-bit, its call stack is 256 bytes, and for real work you need to use the zero page (zpage) well. None of these are likely to relevant to a modern software developer using assembly. Its design encourages the use of global locations, again, an approach that don't make sense on modern systems.
I say this as someone who admires what the 6502 was able to achieve in its time, and I even have a long-running page dedicated to the 6502: https://dwheeler.com/6502/
If you want retro and easy, the 68000 has it beat in terms of simplicity of development. The 68K is quite regular & a little more like modern systems (sort of).
However, I think starting retro is often a disservice. Most the time the reason to use assembly is performance. If you're running code on chips more than a dollar or so, getting performance out of modern architectures is MUCH different than retro computers. For example, today a lot depends on memory cache latency, yet is typically not a serious concern on most retro computers. So learners will learn to focus on the wrong problems.
If you want a modern simple architecture, may I suggest RISC V? That's under a royalty-free open source license, and real computers use it today. It's pretty simple (your basic load-store architecture) and you can pick only the modules you care about. Full disclosure: I work for the Linux Foundation, but I'd say that anyway.
Plausible alternatives are ARM and x86. If you subset them, they're okay.
The reality is that assembly languages reflect the underlying system, and that will change over time.
LibreOffice makes this especially easy to do: https://wiki.documentfoundation.org/Faq/Writer/PDF_Hybrid
I propose that when translating such statements to a formal logic, if that's what you really mean, use an "allsome" quantifier as I've described here: https://dwheeler.com/essays/allsome.html
It's really easy to forget to include an existence quantifier. Having notation specifically designed to automatically include it can avoid some problems.
> If one were to attempt to identify a single failure of Gopher in competition with the web, it would be the licensing costs. No such fee existed for the World Wide Web.
This, a thousand times. I watched as this happened. The instant that announcement was made, gopher was finished. Gopher might have lost later as HTML kept adding features, but by the time those features were added to HTML, gopher had already lost.
I run a Rails app; I switched to Postgres years ago and never looked back. Postgres is awesome. Still, it's great to have alternatives available, and I use sqlite for other tasks, so I know it has good capabilities too.
The first thing I did was check if the publication date was April 1. I'm not entirely sure I believe this article. However, if it's satire, it's impossible to be sure. I guess it's real, and the world has gotten weirder.