libera/#commonlisp - IRC Chatlog
Search
13:18:33
lisp123
Swift / Objc --> Apple | Python, Java --> Google | JS --> Browsers | C/C++ --> General Powerhouses
13:22:59
pranavats
lisp123: What's the context? Some might find its independence from any single powerful interest group appealing.
13:39:11
lisp123
but i see nothing in lisp that prevents it from being as popular as other languages, but in any case I'm more than happy as it is :) to rotateq 's point
13:39:48
rotateq
Do we need being overhyped? :) And as big as some company can be, it can be nothing from one day to another.
13:44:54
yitzi
lisp123: I think you assuming learning lisp is the same level of difficulty as all other languages. In my opinion CL is a very advanced, powerful and expressive language. Which basically precludes it from being popular. Most of the popular languages are the exact opposite: basic, weak and restrictive. Just my opinion.
13:46:13
lisp123
yitzi: I agree to a degree with that viewpoint, but I wonder if thats partly with how programming has been taught (a lot of potentially bad habits / unclear concepts in other languages)
13:47:33
lisp123
Also I find the difficulty with lisp _may_ be in how simple its semantics are --> instead of churning out boilerplate, it forces one to think more deeply at an earlier stage
13:48:23
lisp123
Which comes back to your point to a large degree, if you numb people down with boilerplate, they don't have time to come up with cleaner, abstract code and just pump in basic pseudocode
13:50:53
yitzi
Since I am self taught, I cannot comment on the relation of any education system to the quality of programmers. In my own disciplines (Math/Physics) the quality of the education system is not purely responsible for a relative dearth of students. The main reason is that they are just intellectually difficult disciplines.
13:52:17
beach
We (me and my favorite coauthor mainly) taught Common Lisp for around 15 years to third-year undergraduates, with some success.
13:53:00
beach
The ones who wanted to get it did. The others hated it because it did not resemble anything they had learned before, and because they didn't think it would be useful to them I guess.
13:53:49
beach
And I don't think the success rate was any lower than that of most courses we taught, i.e., around 20% or so.
13:59:25
beach
So yes, a large part of the problem is that we crank out masters-level graduates with knowledge only in fairly traditional programming languages and programming techniques.
14:00:44
beach
My favorite coauthor is considering teaching it again, but then the problem is that there are almost no colleagues qualified to do the lab classes.
14:03:11
seok-
lisp123 has a point that there's not much financial motivation for students to learn CL
14:04:36
beach
I don't think that's the problem. Most students here have no idea what to expect when they get a job. It was a problem when we taught it at the engineering school because they are highly career oriented. But at the university, they really don't know.
14:05:41
beach
The university students really just want a degree with as little effort as possible, and Common Lisp seemed like a lot of effort when they thought they already know everything they would ever need.
14:10:01
pranavats
I rather like that most CL programmers I encounter have internal motivation to do it. External motivations often last only as long as the stimulus motivating them.
14:10:16
dlowe
early work was done in CL (due to its AI reputation probably), so you have to learn CL in order to read the papers
14:10:30
dlowe
and they're not programmers, and they'll be damned if they have to learn another language
14:11:29
dlowe
I learned CL as part of a skills acquisition lab. They had a cognitive model (that was a Hopkins NN but they didn't know that)
14:11:42
pranavats
seok-: See ACT-R, a theory in Cognitive Science. It is still being actively developed in CL.
14:15:26
Shinmera
I can help with the job problem if people give me more money to spend on Lisp programmers :)
14:16:28
seok-
I assume a lot of them don't even look because they're sure they are not going to get applicants
14:16:56
Shinmera
Speaking of that, there'll be a Kickstarter for Kandria launching in June, so pretty soon! If you want to pitch in, check it out: https://kandria.com/kickstarter
14:31:59
lisp123
the more median programmers come to CL, the more bad frameworks / libraries and the higher signal to noise
14:34:28
Shinmera
ah man who cares. We already have an overflow of libraries. It doesn't matter. What matters is that the more people we get in, the more likely we'll get people that improve existing solutions, too.
14:35:10
Shinmera
The kinda elitism about "oh *those* people aren't good enough" is not helping anyone.
14:39:05
Shinmera
I would like to be hiring, but do not have the funds to do so except to offer bounties for very select things I need (which I am doing already).
14:40:11
Shinmera
Well someone could if they wanted to. See Kickstarter above, and https://github.com/sponsors/shinmera
14:40:13
tychoish
also building really ergonomic tools to do the things that make existing shops be able to do a little thing with CL (e.g. more support/connections to databases, stream processing tools, and gRPC stuff) will mean that CL can do the land-and-expand thing and not depend on companies making their entire play "use CL"
14:41:44
tychoish
there's so much code that needs to be written and people with money who would be willing to pay for it.
14:45:53
Shinmera
The games industry is already bad enough at exploiting peopel's passion for profit. I don't want to add to that.
14:46:13
Shinmera
That said, if someone wants to do stuff because they feel like it, Trial and all supporting libraries are open source.
14:47:04
lisp123
Fair enough. I think you may find a few people (maybe 1 or 2) who would be keen to work on a project as a volunteer, and if you set a condition to agree to pay them X if the project is successful, I wouldn't feel too bad
14:47:27
lisp123
Esp if they are allowed to take their code and use it as part of the resume for future jobs
14:48:24
lisp123
Biger problem ofc is without paid work, people tend to disappear after the initial excitement
14:48:47
lisp123
Which is why we have so many grand ideas to improve lisp, but things move alot more slowly than our imaginations ;)
14:49:54
Shinmera
lisp123: I would only agree to such a thing if the person in question was a co-founder of the company. But I deem it very unlikely that I would find someone willing to go that far.
15:08:27
tychoish
all of the stuff that people do is accessible via gRPC and a lot of stuff is WASM-able so like, it wouldn't be too hard (in theory, of course) to write/ship CL code to do things (including some easy tooling things,) but
15:10:13
tychoish
I mean, I come from a database background, and like statemachines are cool, a lot of what people are doing with them are... marginally grounded in practical use cases, but there is some stuff that I think has some merit, and I think building things that are more useful is definitely a thing that would help.
15:11:04
tychoish
https://cosmos.network/ and https://github.com/tendermint/tendermint (I think tendermint.com ends up going to a confusingly sibling project )
15:12:37
tychoish
anyway, feel free to chat with me out of band, I don't want to take up space here, as it's somewhat orthogonal, but I think the higher level of my point is "the thing that stops CL (or anything) from getting adoption in areas like this is support for interrop around the edges (e.g. in our case gRPC and wasam)"
15:17:13
tychoish
there is, there isn't TLS support (which is a big caveat) and limited async support (which is a very small caveat.)
15:26:43
tychoish
async is great, and I can't see why we wouldn't be able to have _some_ kind of async operation, I think it's just less off an issue than the other, because you can fake it on the client (or server) with threads if you need to, and you often don't need to?
15:27:34
tychoish
whereas not having TLS is often a hard barrier to adoption before you really get started
15:29:51
Bike
does TLS mean thread local storage here, or transport layer security, or something else?
15:44:38
dbotton
"the more median programmers come to CL, the more bad frameworks / libraries and the higher signal to noise" list123 - The vast majority of what a master writes in is life is "subpar" in fact the only way to be sure to get one good library is to have written hundreds of bad ones
15:45:45
dbotton
the vast majority of any huge library of code is garbage, what is worthwhile floats to the top, the rest gets to make the numbers look better for everyone
15:45:50
White_Flame
the ecosystems out there rely on cobbled together hacks, and that becomes familiar to many programmers
15:46:11
White_Flame
and there's very little pushback to bad infrastructure from those other languages, and just accept them
15:48:44
White_Flame
dbotton: there's a big problem with that, though, in that experienced people or those who work with more complex problems have different definitions of what's "worth using"
15:49:20
White_Flame
for people whose majority of coding is instantiating and connecting framework-provided tools, there's little notion of need of anything well-engineered
15:49:45
lisp123
dbotton: I would recall my earlier comment, I was just thinking out loud and don't have a strong leaning towards that anymore. A better way to rephrase is - everything I need in CL already exists, so I don't care about its popularity
15:50:53
White_Flame
for example, metaprogramming is hugely important to me, and most other languages/ecosystems leave programmers with no notion of it at all (or appropriate the term poorly)
15:51:33
Guest74
mfiano: I agree with you. I think lisp is a language that you can bend to your will, and not bend to its. You can see people's personalities and thoughts in their code. It's even more apparent in things like AoC. So it's less about finding someone that programs lisp, but who thinks the same too.
15:52:31
Guest74
Of course, this doesn't disqualify cogs in a machine programming, which is probably what we need more of. Bring on the grunts.
15:53:53
tychoish
lisp123: grpc really wants to terminate ssl at it's endpoints (and use it for client auth, for example,) using nginx to terminate SSL/TLS for grpc often doesn't work in practice.
15:55:58
White_Flame
for me, I think asm, forth, and lisp are proper coverage of getting computers to do things. then add prolog to the mix to get out of imperative thinking
15:58:21
tychoish
I've definitely done most of my programming in professional situations, and think that (in general) people really like writing software that other people are going to use (which is why I sort of skew towards potentially (quasi?) industrial applications, and being able to sort of increase relevance based on that.)
15:59:28
tychoish
also the thing I really like about making software, in addition to shipping things that people actually use, is being able to work with other people on said software (and making them better programmers, and becoming a better programmer)
15:59:55
tychoish
so while like "oh we need more plumbing" is kind of uninspiring as a goal, I think it's important.
16:00:37
White_Flame
tychoish: yeah, that's similar to a basic mantra of coding: "Always have a running version". It keeps satisfaction high
16:01:19
lisp123
hmmm i think the quality of lisp materials is exemplary - and one can learn to be a very good programmer from them, BUT it requires self study
16:01:51
White_Flame
I think learning to be a very good programmer is orthogonal to what you learn from those books
16:02:10
tychoish
I think you gotta work on things with other people and learn to write good tests and stuff.
16:02:24
White_Flame
I'd say the ability to see the need for abstractions, and to be able to create them well, are the most important facilities to grow, and that's rarely touched upon
16:02:47
dbotton
or in the lang here - protocols are poorly defined and there is poor means to do it
16:03:19
tychoish
anyway, I think it's less about libraries in general and more "libraries around the edges," lisp is kidna great once everything's in lisp, and a kind of a nightmare if you want to get data into our out of it (and into some other kind of system)
16:05:19
dbotton
the fact that a function symbol name is all that one can specify, can't compile the specs separate etc
16:06:48
tychoish
I think this idea that the compiler should save you from everything or that you can have a compiler should be able to enforce all the constraints, always feels incomplete. like software without side effects doens't do anything, and compilers which try to do too much, are just slow and difficult to work with. so there's always a trade off there, and writing tests makes you have to actually think about how your APIs are used, and that's
16:07:14
White_Flame
dbotton: I'm not talking abotu interfacing between modules, I'm talking about creating new abstractions
16:07:50
White_Flame
whether it's just creating better function protocols, or creating new DSLs and build tools, an abstracting mind shouldn't ever be constrained to a single perspective of tooling
16:09:33
White_Flame
programming languages are just one layer of tools, built by someone, and building better tools in both the small and large is how we advance overall
16:09:54
White_Flame
the ability to see the need for a new tool, however, seems to be limited. once one learns a tool, the easy route is to see how it's applicable to everythign
16:11:14
White_Flame
while I'm not very familiar with Ada, haskell has similar claims re its type-first development perspective and compiler support
16:11:58
White_Flame
and similar "if it compiles, it will work" claims that do not cover a whole host of bugs
16:14:10
White_Flame
of course, the conglomeration of language branches into Common Lisp was the core language itself, as everyone had their own tooling
16:14:48
White_Flame
it's a large and non-CL-standard effort to get that sort of things back into the CL community
16:15:23
White_Flame
and people worship emacs, which isn't even an IDE in the commonly thought of sense, locking people in a "good enough" state of tooling :-P
16:16:39
White_Flame
SLIME is great for interactivity, but it doesn't reach much into actual project management at all
16:16:40
Guest74
anyways, all communities go through stages. We haven't finished the library wars yet.
16:17:50
White_Flame
I don't think it's useful because there's too diversified opinions of what should be worked on
16:18:07
White_Flame
commercial efforts do focus people, but then also pull stuff away from community use
16:18:29
White_Flame
and it was only durring the commercial lisp days that this sort of stuff really advanced
16:19:58
Guest74
I think part of the answer lies in making a generic infrastructure of 'missing' components. A set of reserved namespaces(packages) that can contain all the necessary stuff to deal with those namespaces.
16:20:52
Guest74
It would help everybody to program together if we had a common language for all the missing bits.
16:23:07
Guest74
yes, but in the generic interface you only stick the bits everybody agrees are needed. Sort of how common lisp came about.
16:25:32
dbotton
but I am looking for an exchange of ideas for things that would help teams work as a team with CL
16:28:54
seok-
It's not just lisp specific but I think a flowchart/node graph generator for visually representing function, symbol and import dependencies would be beneficial for individuals or groups looking at a codebase
16:29:39
White_Flame
you develop abastractions in a group by constant communication, and holding off implementing new ideas until they've percolated through thoughtful people for a period of time to the point where it's bonked against raised issues, solutions arose, and it settled into established confidence
16:31:22
Guest74
I envision a system that is less about text files stored in a repository and more a collection of interchangeable annotated functions/packages.
16:32:00
White_Flame
the time cost of prototyping & refactoring need to be taken into account. If it's a familiarized problem with uncertain solutions, the time needs to be spent in consideration
16:32:37
dbotton
for many parts of a system that are critical, maybe multiple attempts to implement and then compare
16:32:58
White_Flame
compare what? the point of abstraction is to make things more easily manageabble in the large
16:33:17
White_Flame
so the only real world measurement is to use it in the large, which is a heavyweight investment
16:36:22
Guest74
I've wondered how much space would be wasted/gained by storing a system where each individual function is versioned.
16:39:47
dbotton
My take away for myself from this - list the things that would make CL teams productive, in person and remotely, and tools needed. This is at each stage: 1. finding the problems to solve 2. abstractions that conform to the problems 3. implementations 4. testing 5. error corrections
16:40:59
dbotton
there is some existing literature mostly from Paul Graham's discussions about his success
16:41:07
Guest74
anyways, since it's cl and nobody usually agrees 100% on a direction, I just slowly write generic systems as I use them. usually in a manner that would anger most people. So all my generic stuff about a font lives in the package font:
16:48:13
Guest74
I just think generic interfaces for things, populated with a bunch of interchangeable documented algorithms would be good for learning and as scaffolding for building ideas, instead of worrying about building tools.
16:49:56
dbotton
I make a point to never develop algorithms until absolutely needed for optimization
16:50:30
dbotton
only a fool develops a sort algorithm before knowing if what exist is not fast enough
16:52:39
dbotton
I have not published yet full docs on wrapping existing components yet for CLOG or did any major examples, but is the key to it
17:03:05
ehammarstrom
What's a common or "best practice" way to write a parser (for a blub language) in CL? In Haskell you'd perhaps write a parser combinator, what's the lispy way?
17:33:20
White_Flame
ehammarstrom: for an existing blub language with all their weird edge cases, or for some new basic language?
18:00:23
yottabyte
someone explained the difference between parallel and concurrent when talking about let, but I don't remember. because let is parallel, but not concurrent. can someone explain it again?
18:00:38
dlowe
but most compilers I'm aware of use recursive descent instead of tables or frameworks
18:03:27
Bike
yottabyte: the values are evaluated in an environment in which none of the variables are bound, so we sometimes say the variables are all bound "in parallel". but the evaluations take place sequentially, so it's not "concurrent". the meaning of "parallel" in the context of LET is totally unrelated to concurrency in the sense of multithreading etc.
19:04:43
White_Flame
yottabyte: (let ((a expr1) (b expr2)) ...) is directly analogous to ((lambda (a b) ....) expr1 expr2) in terms of when the exprs are evaluated, and when A & B come into existence
19:06:18
dlowe
(let* ((a expr1) (b expr2)) ...) is analogous to (let ((a expr1)) (let ((b expr2)) ...)) in the same way
23:07:50
lisp123
and its documentation / code seems top notch...not suprised ;) Definitely the option to go for for anyone looking to implement editors in the browser
23:58:54
bollu
is the `compose` function to compose two functions available somewhere in the CL stdlib?