2022-01-03 05:21:21 CJlisp 2022-01-03 05:21:33 ^ Sorry 2022-01-03 05:21:57 Although, speaking of which: https://joshbradley.me/understanding-the-power-of-lisp/ 2022-01-03 05:25:45 > as languages mature, the average language continues to slide towards LISP[citation needed] 2022-01-03 05:27:59 Skipping the cruft, the only part I liked is the "the universal function". I think this may have been mentioned in the sectorLisp post earlier, and also probably in most Lisp books. I wasn't aware of the term. 2022-01-03 05:29:07 I'd still rather write pretty much any language other than Lisp 2022-01-03 05:31:05 My first Lisp was with Emacs Lisp, and it was quite smooth. It is not very unlike many contemporary languages, especially thanks to the popularity of FP style. 2022-01-03 05:32:05 I find it quite fast and easy to write programs with. It feels natural and effortless to express "list processing" problems with it. 2022-01-03 05:32:22 IMO it's more similar to your average dynamic typed scripting languages than the contemporary languages that add "FP style" 2022-01-03 05:32:23 That is, when you think in terms of map, filter, reduce, etc. 2022-01-03 05:32:39 That is true 2022-01-03 05:32:48 It feels like a toy language too 2022-01-03 05:33:30 Every serious lisp doesn't feel like a toy, it feels like a hammer with 10 heads and everyone swears by needing each of those 10 heads for different nails 2022-01-03 05:33:43 Simple, and it works. I read that instead of JavaScript it was almost going to be a Lisp in the browser. 2022-01-03 05:34:01 Common Lisp and the likes indeed feel ginormous. 2022-01-03 05:34:36 The decision to make JavaScript a C-like language was good, the MS thing would have won if they had picked lisp 2022-01-03 05:34:47 Good point, didn't think of that 2022-01-03 05:35:47 You pretty much need an IDE to edit lisp because lispers have religious sentiments about where your parentheses go, and they didn't pick the more visually/structurally obvious one 2022-01-03 05:36:11 So I have to use an IDE to write lisp code that I won't get ridiculed for writing, and I (and probably everyone) finds it harder to read 2022-01-03 05:37:18 That is also true, but a bit trivial nuisance for me. 2022-01-03 05:37:20 And I know that sometimes you want to nest more than one list on a line before an indent, but that's still easier to match correctly with ending parens on each end of indent 2022-01-03 05:37:42 It's not even trivial, I feel it slowing me down, if a community makes me do stuff that slows me down I ignore it 2022-01-03 05:37:53 On another note, during my vacation I somehow decided to sit down and start liking and catch up with the new C++ features (actually I wasn't even fully up to date with C++98 esp wrt templates). I think I'll continue filling my gap in some of that stuff. 2022-01-03 05:38:09 That means I can't write lisp that will ever be used by lispers, so I might as well not bother because good programming is at least a tiny bit social 2022-01-03 05:38:24 (My theme for the new year: Give a second chance to things I hate) 2022-01-03 05:38:38 s/second/Nth/ 2022-01-03 05:38:39 Go for it, C++ will quickly push you away again 2022-01-03 05:38:53 I've given a few chances to lisp 2022-01-03 05:45:30 C++ is just very large and complicated, it doesn't warrant it by making things easier to write. Only experts seem to be able to write fast C++, the average C++ is slower than what a rookie C coder writes without even meaning to. 2022-01-03 05:46:20 Templates are mostly an excuse to unnecessarily duplicate code most of the time, they have some real applications that seems to be a minority of their usage in reality 2022-01-03 05:54:47 One thing I'm conflicted is that I find value in type systems and overall code correctness/static-analysis DSLs. For example I like the conceptual tools in managing memory in C++ (move/copy semantics, smart pointers, RAII, etc). But the amount of complexity, and this sense of imaginary work that's created all feels yucky at times. 2022-01-03 05:55:05 Similar thoughts with OOP 2022-01-03 05:55:55 Type safety =/= safety, it is a tool and it's less helpful than you might think 2022-01-03 05:56:39 For example, trying out every word/function and checking it works is more powerful than a type system for finding bugs most of the time (especially if it's short) 2022-01-03 05:57:13 FORTH has no type system but we manage to develop large programs with relatively few bugs, because we test each word and keep them small 2022-01-03 05:59:20 One other aspect of type systems is to communicate the correctness to others (and communicate information about the data, which otherwise is implicit). 2022-01-03 05:59:39 For this, I was entertaining the idea recently that in Forth you could inline your tests as well. 2022-01-03 06:00:11 That is, as the code gets compiled, your tests would run for each word, which don't end up in the dictionary (or can be cleaned once done). 2022-01-03 06:00:24 The issue is that nobody is good at naming the types used to communicate this, you end up reading loads of badly written docs trying to source the write classes for your job 2022-01-03 06:00:38 If the type system is dumb you just have "here are the functions that do stuff" and you make it work 2022-01-03 06:08:35 In real life not everything is a small number of Shape's, Circle's, or Rectangle's. And not every problem is "what is the area of each shape?" 2022-01-03 06:09:36 As soon as I ask a slightly different question, like "what is the area of the largest shape" a healthy mind immediately stops thinking in OOP and starts thinking "how can I structure those shapes to answer this question straight away" 2022-01-03 06:11:24 The C++ programmer fails at the "there is no spoon" step, because if I have a load of data and want the largest, I'm just storing a max area and then I don't even have to worry about how I can store them all at once, or which class hierarchy to use, it's just a very simple problem and I'm solving it 2022-01-03 06:14:14 Does the C++ programmer consider that their objects don't even own their data? It lives in many places, in I/O or in storage. They now need serialisation libraries to cope with that which breaks down depending on how they implemented the classes that need storing. Again they're solving problems that don't need solving. 2022-01-03 06:16:07 Because their programs aren't data, and their 'objects' aren't abstract. A program is a program, it processes data. OOP mindset makes you think first about the 'objects' even though the useful/meaningful/efficient representation of the objects depends on how you need to process them, and what algorithm you will use 2022-01-03 06:16:59 I say all this because I was also a C++ programmer, and I thought about all this stuff too, and have painfully returned to the ideas of OOP many times over. 2022-01-03 06:18:18 A C++ programmer finds an old C library with 5 functions that do everything they need and then moan about how it uses raw arrays and pointers as they immediately wrap it into their classes: so they understand how to use it immediately, this is what annoys them the most. 2022-01-03 06:34:13 Haha, good quality rant. 2022-01-03 06:46:10 I think there is an element of not only solving the coding problem at hand, but also controlling the programmers, i.e. how the code should be written, by incorporating structure into the language itself and thus enforcing. 2022-01-03 06:48:03 Small example. A Class, first acts as nothing but a "framework" that enforces certain simplistic patterns that all code shares, but is usually implicit: namespace, entry point, encapsulation. This stuff is done one way or another in other languages, but without an enforced framework for it. This does not mean to employ full fledged OOP mindlessly (but there lies the devil). 2022-01-03 06:49:19 I think the devil is turning it into an ideology 2022-01-03 06:49:42 When you run a shop, and you hire a bunch of coders that may leave overnight, you try to enforce as much structure as possible to make the code look similar. But the coders turn it into a philosophy. 2022-01-03 06:49:59 OOP is an ideology that you will solve problems better, write more maintainable code, write code overall faster, if you apply at least some of its tenets 2022-01-03 06:51:47 It's total BS, every tenet of OOP is bad either sometimes or most of the time. But it's like a 'game' you can play writing programs that makes you feel good, like you're doing something useful. I believe it is an illusion 2022-01-03 06:52:40 I will attack even encapsulation, which is the most reasonable-sounding part and which is possible in pretty much every modern language including even C and FORTH 2022-01-03 06:55:48 I think only weak encapsulation is good, where you divide code into different 'modules' to organise it when it makes sense, but you are prepared to almost entirely expose every module to every other module if it's convenient 2022-01-03 06:56:40 For me, static definitions in C are just there to avoid name collisions and express intent that this is 'private', but the second I write something similar in another module I would (in a code base with standards) move it to a 'utility' or 'shared' module 2022-01-03 06:57:48 Why not just expose it there, 'utility' and 'shared' etc mean nothing. Even modules you have 'shared' between a subset of modules in some kind of imaginary structure is hiding good code sometimes. Just make the bloody thing extern, make it flat 2022-01-03 06:59:06 This mindset used to be more common, why else do you think memcpy is in string.h? Unfortunately these days that wouldn't pass review! 2022-01-03 07:01:36 neuro_sys_: Also don't "run a shop" where the coders "may leave overnight", that causes trouble regardless of how the code is written. I see a lot of code that would pass all code reviews/standards with good documentation ignored because "the guy that wrote it left, nobody understands it" 2022-01-03 07:04:16 In that scenario the problem isn't the code, the problem is that people are leaving, although I understand that's the whole culture in america right now 2022-01-03 07:05:22 And strongly incentivised, that's how a lot of people get higher salaries, they're being paid to let half their projects die and go waste time learning/rewriting someone else's half-baked projects. From 1000 yards it's clear this is not productive... 2022-01-03 07:05:32 but as long as the money keeps trading hands everyone's happy 2022-01-03 07:36:50 > don't run a shop where the coders may leave next day 2022-01-03 07:37:16 Need to fix capitalism or free market for that I suppose. Some/most people are in it just for the money, not for the craft. 2022-01-03 07:37:59 Or not just necessarily that, but that the owner may not have enough time or chance/skill to hire good engineers. 2022-01-03 07:39:24 Even when you are the coder yourself, you want to reduce the time it takes to onboard a new engineer. Languages with "ideological" frameworks built into them allows that. 2022-01-03 07:42:04 I work at a small engineer-founded company that uses CL (among many other languages) and IME we have a harder time "integrating" a new hire to a Python or C++ project than a CL one 2022-01-03 07:43:23 my hypothesis is that it's got enough bizarre stuff (the entire pathname functionality, format strings) and enough "obvious" footguns (non-hygenic macros, MOP) that people are a lot more willing to accept vigorous code review until they're acculturated to local style 2022-01-03 07:43:50 When you have things like C++, and OOP in the mainstream, it is an industrial agreement on how the code should be written, as enforced by the language itself. This reduces the cost of new hires. 2022-01-03 07:44:08 (I was still typing this before you posted remexre, it's not a response to that, let me read) 2022-01-03 23:35:54 neuro_sys_: in terms of making C++ fun, I quite like Qt core -- Qt's non-GUI-related data structures and libraries 2022-01-03 23:36:01 It makes C++ much, much less stupid