171–180 of 204 posts
Earlier quoted context omitted.
> Well, for regular macros, only if your C syntax was in a string. Otherwise, lisp would try to tokenize it, and choke. Which is why I said normal (rather than reader) macros could do a "basically C-like syntax" but with Lisp tokenization rules.
What would that look like?
((:include "stdio.h")
(const char * message = "Like this.\n")
(int main ((int argc) (char * * argv))
(printf message)
(return 0)))Earlier quoted context omitted.
> COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Sure. But these systems were created from the ground up, every single time. Given a good foundation, which could be Lisp or something even better, you can whip u…
Lisp didn't miss the train because it was too good or because people were idiots. For a good foundation to be good it has to meet the pre-requisite to work for most use cases. Lisp didn't when C did, in a time when hardware was small and expensive. Times have changed now? Sure, but history didn't wait.
Earlier quoted context omitted.
if the industry were really striving for perfection, there would be no COBOL or BASIC, for instance. COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Beginners might be overwhelmed by OOP, multiple dispatch and a…
> BASIC is a good demonstration of why the platonic ideal language is wrong That's often my point when people bring up arguments against a language that seems a bit more complex (Perl), or for language simplicity (Python). Some complexity falls into a sliding scale where there is more cognitive load while learning, but it pays of in the every day usage. The siple example of an extreme end of this is APL. If you can i…
I think quite a lot of complexity falls into this scale, and the quest for simplicity - or rather, "user-friendliness" - in computing is utterly misguided. The difference between a toy and a tool is that a tool exchanges more upfront learning requirement for ability to get more done. Not just more efficiently, but more. We're doing ourselves, and the world, a huge disservice by expecting that everything - be it a website, an IDE or a programming language - should be able to be mastered in first 5 seconds of exposure. The only way to achieve that is to dumb the product down.
In other words, we need more learning culture (or even RTFM culture), less "user-friendliness".
Earlier quoted context omitted.
The majority never picks the best and markets do not optimize as much as some people think. Whether it's movies, arts, books, music, politicians, keyboards or programming languages, the most popular choices are practically never the best ones. Which is probably why a technocracy in which every voter must pass a fact-based proficiency test before being allowed to vote might trump democracy. Not sure, just wanted to ch…
Who gets to determine which facts? Why would that group not use that to their advantage, instead of to the benefit of everyone? > The majority never picks the best and markets do not optimize as much as some people think. Whether it's movies, arts, books, music, politicians, keyboards or programming languages, the most popular choices are practically never the best ones. The question is not whether the market picks t…
The experience of the entire Internet seems to suggest a different answer, so it's not that central planning is always bad. Note that the best, most reliable, most stable parts of the Internet were invented and codified long ago, when there weren't many people on-line and there wasn't that much commercial interest in it. Today we can rarely if ever agree on any kind of protocol or standard, and if we do, it's usually a huge bloated mess.
> A way to create a new language in just a few weeks As a Lisp programmer, I regularly create new languages in a matter of hours.
Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.
Implementing C as a parser that builds s-expressions followed by a collection of macros to translate it into Lisp is certainly possible; I did it in 1984. I wouldn't say it was trivial, though; nor was the performance anything special (even then).
I will definitely take a closer look at Graal and Truffle.
Earlier quoted context omitted.
Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station contro…
>As a side note, just check how many Android releases are they going through and yet real-audio support isn't quite there Actually, there is. As of Android 6.0 Google's CCD includes a section for Professional Audio devices If a device implementation meets all of the following requirements, it is STRONGLY RECOMMENDED to report support for feature android.hardware.audio.pro via the android.content.pm.PackageManager cla…
They even had Samsung on stage to talk about their Android extensions for real-time audio.
So with Android 6.0 barely over 10%, still with issues fixed in Android 7.0, it is as I said "real-audio support isn't quite there".
Earlier quoted context omitted.
> COBOL was a huge improvement at the time, an innovation in readability. BASIC is a good demonstration of why the platonic ideal language is wrong: it was designed for beginners (that's what the acronym stands for), and it did a reasonably good job at that. Sure. But these systems were created from the ground up, every single time. Given a good foundation, which could be Lisp or something even better, you can whip u…
Lisp didn't miss the train because it was too good or because people were idiots. For a good foundation to be good it has to meet the pre-requisite to work for most use cases. Lisp didn't when C did, in a time when hardware was small and expensive. Times have changed now? Sure, but history didn't wait.
Lisp usually required expensive mainframes and workstations.
Of course C got the adoption of the 80's hipsters with such price tag.
There's actually a fairly long history of cross-language VMs, with various degrees of success. What usually happens is that they work fine for languages that look, semantically, basically like the native language on the VM. So LLVM works well as long as your language is mostly like C (C, C++, Objective-C, Rust, Swift). Parrot works if you language is mostly like Perl 6 (Perl, Python, PHP, Ruby). .NET works if your la…
> The JVM works if your language is mostly like Java (Java, Clojure, Scala, Kotlin).
I'm really curious why you're characterizing Clojure as "mostly like Java"?