> Another reason patents are nice is that it's that you get something for your actual contribution. This means that it offers particularly skilled people who aren't rich a chance to actually build a company and have something real.
... assuming you have the money to defend your patents (or even just find violations). Also, Bigco will just patent adjacent things like production processes and then force your company to trade. How many "small guy" patents were there in the recent years? It just does not fit to our world anymore.
Having a simple syntax might be fine for computers but syntax is mainly designed to be read and written by humans. Having a simple one like lisp then just makes syntactic discussions a semantic problem, just shifting the layers.
And I think an complex syntax is far easier to read and write than a simple syntax with complex semantics. You also get a faster feedback loop in case the syntax of your code is wrong vs the semantics (which might be undiscovered until runtime).
Jury's out re: whether I feel this in my gut. Need more time with the lisps for that. But re: cognitive load maybe it goes like:
1. 1 language to rule them all, fancy syntax
2. Many languages, 1 simple syntax to rule them all
3. Many languages and many fancy syntaxes
Here in the wreckage of the tower of babel, 1. isn't really on the table. But 2. might have benefits because the inhumanity of the syntax need only be confronted once. The cumulative cost of all the competing opinionated fancy syntaxes may be the worst option. Think of all the hours lost to tabs vs spaces or braces vs whitespace.
I dunno, here in 3 the hardest part of learning a language has little to do with the language itself and more to do with the ecosystem of tooling around that language. I think we could more easily get on to the business of using the right language for the job if more of that tooling was shared. If each language, for instance did not have it's own package manager, its own IDE, its own linters and language servers all with their own idiosyncrasies arising not from deep philosophical differences of the associated language but instead from accidental quirks of perspective from whoever decided that their favorite language needed a new widget.
I admire the widget makers, especially those wrangling the gaps between languages. I just wish their work could be made easier.
I really like the Linux package managers. If you're going to write an application that will run on some system, it's better to bake dependencies into it. And with virtualization and containerization, the system is not tied to a physical machine. I've been using containers (incus) more and more for real development purposes as I can use almost the same environment to deploy. I don't care much about the IDE, but I'm glad we have LSP, Tree-sitter, and DAP. The one thing I do not like is the proliferation of tooling version manager (NVM,..) instead of managing the environment itself (tied to the project).
I've always thought these complaints are really just a reflection of how stuck we are in the C paradigm. The idea that you have to edit programs as text is outdated IMO. It should be that your editor operates on the syntax tree of the source code. Once you do that, the code can be displayed in any way.
I also believe this, and we're actually about half way there via MPS <https://github.com/JetBrains/MPS#readme> but I'm pretty sure that dream is dead until this LLM hype blows over, since LLMs are not going to copy-paste syntax trees until the other dream of a universal representation materializes[1]
The problem with this statement is that it assumes parsing-easiness as something universal, and stable. And this is certainly not true. You may believe syntax A is so much easier simply because it's the syntax you have been dealing with most of your career thus your brain is trained for it. On top of it a particular task can make a lot of difference: most people would agree that regex is simplification versus writing the same logic in usual if-then way for pattern matching in strings, but I'm not sure many would like to have their whole programs looking that way (but even that could be subjective, see APL).
This is interesting. My first thought was that a language where more meaning is expressed in syntax could catch more errors at compile time. But there seems to be no reason why meaning encoded in semantics could not also be caught at compile time.
The main benefit of putting things in the syntax seems to be that many errors would become visually obvious.
lisp's syntax is simple - its just parenthesis to define a list, first element of a list is executed as a function.
but for example a language like C has many different syntaxes for different operations, like function declaration or variable or array syntax, or if/switch-case etc etc.
so to know C syntax you need to learn all these different ways to do different things, but in lisp you just need to know how to match parenthesis.
But of course you still want to declare variables, or have if/else and switch case. So you instead need to learn the builtin macros (what GP means by semantics) and their "syntax" that is technically not part of the language's syntax but actually is since you still need all those operations enough that they are included in the standard library and defining your own is frowned upon.
Lisp has way more syntax, that doesn't cover any of the special forms. Knowing about application syntax doesn't help with understanding `let` syntax. Even worse, with macros, the amount of syntax is open-ended. That they all come in the form of S-expressions doesn't help a lot in learning them.
Most languages' abstract machines expose a very simple API, it's up to the language to add useful constructs to help us write code more efficiently. Languages like Lisp start with a very simple syntax, then add those constructs with the language itself (even though those can be fixed using a standard), others just add it through the syntax. These constructs plus the abstract machine's operations form the semantics, syntax is however the language designer decided to present them.
Not entirely. E.g. IntelliJ has a "project environment" modal (not sure about the exact name rn), in pycharm its part of the settings and a bit different. There are a few more things like this between the IDEs.
To +1 this: yes, they clearly share a lot of code, and have mostly-identical plug-in interfaces, and many dedicated IDEs have plugins for the more-general Intellij IDE.
And they present them as "just" a dedicated UI around the plugins.
But no, they are not actually the same. Essentially ever. The dedicated IDEs often have features that never make it into their plugins, and a lot of the UX and project structure/preferences/etc are quite specialized and don't always have equivalents outside it. You get like 90-95% with the plug-in, but not 100%, and sometimes that's a critical difference.
The plugins do have the distinct benefit of allowing you to use multiple in a single project, though.
As soon as I notice that I got this slow-fade-captcha, I will intentionally click all the wrong fields until I get a reasonable captcha. Not sure this makes a difference but it kinda works
A 2018 paper by the same authors [0] (referenced in this work) references an earlier blog post by the transitapp people on Medium, but the link is no longer working.
> One approach that seems to use a model similar to ours was described by Anton Dubreau in a blog post
> add support for a "max fan speed" slider somewhere prominent in the Windows UI.
Isn't that what the "power settings" do? It's a slider at the bottom right, hidden in a tray icon. Sure, it only has three positions and also influences battery consumption but it pretty much does what you want. (Not sure if windows 11 kept this though)
... assuming you have the money to defend your patents (or even just find violations). Also, Bigco will just patent adjacent things like production processes and then force your company to trade. How many "small guy" patents were there in the recent years? It just does not fit to our world anymore.
reply