41–50 of 63 posts
If you want to actually say something, don't do it like this.
Earlier quoted context omitted.
But that's because all the languages you know are basically dialects of each other because they all descend from ALGOL, not because they are inherently easier to understand. Similarly, someone trained in Lisp would find things like Scheme and Clojure easier to understand than something like Python because those likewise are dialects of Lisp. I'd strongly recommend studying languages different from ones you know -- th…
An objective test of "easy to understand" would be, how close does the code look, to how a programmer might pseudocode it on a whiteboard? I don't recall seeing much significant difference between how Java, Python, or Javascript devs pseudocode on a whiteboard, so it's something approximately close to how a human thinks about it in the absence of syntax issues. I think Python code looks closer to this pseudocode than…
In sum, using pseudocode is just temporarily liberating yourself from pesky syntax adherence in prder to better quickly iterate over an idea, but in that discussion you always have the target in mind from the onset.
It's kind of interesting in the 2001 essay that invented blub it was suggested as a hypothesis as to >And if Lisp is so great, why doesn't everyone use it? Suggesting programmers in a blub language don't realise it's power. I get the impression in the 18 or so years subsequently that the main reason for the low uptake of Lisp is it's power enables people to write clever code that other programmers have quite a job to…
But in another problem domain, Lisp is terrible. I wouldn't want to program an embedded system with memory-mapped I/O in Lisp. I wouldn't want to do high-performance computing, where I had to get the memory alignment right to get the best performance.
Lisp might be like a Formula 1 racer. If you ever drive one, it will probably revolutionize your idea of what a car can be. Just don't try to drive it on a four-wheel drive road - a Jeep will absolutely dominate it there. For that matter, a Formula 1 car is not even a very good car for commuting to work - not street legal, lousy gas mileage, too high maintenance.
And this is what's wrong with the Blub Paradox idea. Power? Power for what? A language has a certain power for a particular kind of problem, and a different power for a different kind of problem. Pick the language that is the most powerful for your problem, not the language that is "the most powerful".
If iOS had required Lisp instead of Objective-C, then Lisp would have been popular right now. Ruby really needed Rails to get people to try it. I think the killer use problem is more an explanation then anything else. Java also showed a good marketing, well funded campaign does wonders.
> If iOS had required Lisp instead of Objective-C, then Lisp would have been popular right now. Probably. I wonder if we wouldn't have ended up with more Xamarins instead.
Earlier quoted context omitted.
> not because they are inherently easier to understand I'm honestly not sure that that's true. I would bet money that someone who primarily works in Lisp would still have an easier time sitting down and reading Python code than someone who works in Python sitting down and reading Lisp, because I think it might truly be inherently easier to understand. There is intrinsic meaning in: x = 5 let x = 5 etc., insofar as th…
There is no such thing as "intrinsic meaning", and I think you might be confusing "human language" and "english-like". There is astonishing variation in human language.
"No programming language is more or less natural than Lisp. It is merely a matter of familiarity and the way most programmers were taught."
One obvious problem is that familiarity does matter. Even ignoring all other programming languages, there is a barrier to climb for the vast numbers of beginner programmers who know English and common math notation like f(x) instead of (f x) and x The other is that for some things, it really does seem like infix notation is inherently preferred by humans. Is there a natural language where conjunctions don't go between terms, i.e. one says "und x y z" instead of "x und y und z"?
Earlier quoted context omitted.
> unfamiliar symbols. If you don't know what is a "cons cell" or the functions car and cdr, for instance. Those short, cryptic names are definitely part of it. It's unfamiliar syntax, and overdose of brackets for added confusion, and in the middle of it all, words that mean nothing to me. Stuff like cout, puts or the printf syntax also take some getting used to if they're new to you, but you get more context with the…
But, on the the bright side, that expression gives you a synopsis of all the syntax you will ever have to know. At least the principal organizing syntax for structuring the bulk of the code. What you don't see there are examples of various minor notations, like various kinds of literals and such. The good news is that parentheses disambiguate everything; if we remove some of them, we have to introduce hidden rules th…
Isn't anyone but me annoyed by the lack of scientific rigor in arguments like these? PG: - It is more efficient to write software in Lisp. Others: - Nah, it doesn't matter. But no empirical evidence has ever been presented...
There is some empirical evidence. I can't find it now but I've seen research showing Lisp beating all languages in terms of speed of creating some programs from scratch by both experienced Lisp developers and students new to the language. Obviously no research for large projects, those can only be researched through things like github data, etc.
Start there, some more links from there to details on the study and follow-ups.
It's kind of interesting in the 2001 essay that invented blub it was suggested as a hypothesis as to >And if Lisp is so great, why doesn't everyone use it? Suggesting programmers in a blub language don't realise it's power. I get the impression in the 18 or so years subsequently that the main reason for the low uptake of Lisp is it's power enables people to write clever code that other programmers have quite a job to…
I agree and will also add that pg seems to have missed some other ingredients of a language's power, especially libraries and tools. Python and Ruby (and Perl before them) got big not just as “easy” languages, but as languages that get the job done quickly thanks to the massive amount of libraries. And while Java, C, and C++ may not be the most elegant of languages, the amount of tools to inspect the code, find bugs,…
Earlier quoted context omitted.
There is no such thing as "intrinsic meaning", and I think you might be confusing "human language" and "english-like". There is astonishing variation in human language.
I really like Lisp and its macros and I don't even mind the sea of parentheses. But I do think requiring everything to be done in prefix notation is a weakness. This is an argument I have seen -- it may not be the one you are trying to make, but your statement reminded me of it: "No programming language is more or less natural than Lisp. It is merely a matter of familiarity and the way most programmers were taught."…
Earlier quoted context omitted.
But, on the the bright side, that expression gives you a synopsis of all the syntax you will ever have to know. At least the principal organizing syntax for structuring the bulk of the code. What you don't see there are examples of various minor notations, like various kinds of literals and such. The good news is that parentheses disambiguate everything; if we remove some of them, we have to introduce hidden rules th…
This actually sounds far more imperative than I imagined Lisp to be. I thought it was mostly a functional language.
In my own dialect of Lisp, TXR Lisp, to demonstrate/test the foreign function capabilities, I took a C code sample from MSDN (a minimal Win32 program to create a Window) and translated it, almost expression for expression:
(deffi-cb wndproc-fn LRESULT (HWND UINT LPARAM WPARAM))
(defun WindowProc (hwnd uMsg wParam lParam)
(caseql* uMsg
(WM_DESTROY
(PostQuitMessage 0)
0)
(WM_PAINT
(let* ((ps (new PAINTSTRUCT))
(hdc (BeginPaint hwnd ps)))
(FillRect hdc ps.rcPaint (cptr-int (succ COLOR_WINDOW) 'HBRUSH))
(EndPaint hwnd ps)
0))
(t (DefWindowProc hwnd uMsg wParam lParam))))
(let* ((hInstance (GetModuleHandle nil))
(wc (new WNDCLASS
lpfnWndProc [wndproc-fn WindowProc]
hInstance hInstance
lpszClassName "Sample Window Class")))
(RegisterClass wc)
(let ((hwnd (CreateWindowEx 0 wc.lpszClassName "Learn to Program Windows"
WS_OVERLAPPEDWINDOW
CW_USEDEFAULT CW_USEDEFAULT
CW_USEDEFAULT CW_USEDEFAULT
NULL NULL hInstance NULL)))
(unless (equal hwnd NULL)
(ShowWindow hwnd SW_SHOWDEFAULT)
(let ((msg (new MSG)))
(while (GetMessage msg NULL 0 0)
(TranslateMessage msg)
(DispatchMessage msg))))))
The full program with all the boilerplate to define Win32 types and bind to the foreign functions is here: http://nongnu.org/txr/rosetta-solutions-main.html#Window%20c...
The original C is here: https://docs.microsoft.com/en-us/windows/desktop/learnwin32/...