freenode/#lisp - IRC Chatlog
Search
6:30:27
drmeister
https://www.dropbox.com/s/27j4i33n7l5n4w7/Screen%20Recording%202020-09-02%20at%202.24.52%20AM.mov?dl=0
13:23:19
beach
I am working on part 3 of my presentations "Creating a Common Lisp implementation" for the online Lisp meeting. I am guessing it will be streamed next week. It won't be as "light weight" as the previous ones. But that's what it takes. There will be some Common Lisp code that we will look at together, and that I will explain as well as I can.
13:28:46
beach
Strategy 1 (that I talked about in parts 1 and 2) was about writing a small core in (say) C, and loading modules written in Common Lisp to obtain a complete system. But, as it turned out, the core had to be much larger than we had hoped. Part 3 is about strategy 2 which is to cross-compile large parts of the system code on an existing Common Lisp implementation.
13:31:04
beach
I guess if part 3 turns out to be to hard to follow for some, it can always be watched again later.
13:31:50
beach
Oh, and those who plan to attend part 3 should try to watch parts 1 and 2 beforehand if they haven't already done so.
13:49:08
jackdaniel
ah, it is nice to see Common Lisp as one of the recommended languages once in a while
13:49:28
jackdaniel
https://begriffs.com/posts/2020-08-31-portable-stable-software.html < cl is only mentioned once, but for a good reason - it has a standard and multiple implementations
13:59:01
beach
jackdaniel: Interesting. When I give talks to industry people, I always say something like "A project leader or decision maker who decides to use a language without an independent standard for some project, should be fired."
14:08:20
jackdaniel
I know, I was a bit surprised I've encountered a similar advice from a person who perfers C (and is apparently not part of lisp community)
14:17:12
beach
Sure. And, although C has a standard, it seems to be evolving regularly. So some of the advantages are lost.
14:31:48
beach
The main topic of talks where this comes up is "risk analysis", which they don't seem to know what it is, in general. And choosing a programming language should be a large part of a risk analysis.
14:44:37
mseddon
beach: for example, if you decide to write everything in coffeescript, it's entirely your fault.
14:46:22
jmercouris
hence why the message of "all of your inferstructure woes would be solved if you rewrote everything in X on this new Y framework" is so appealing
14:47:04
mseddon
and so, on cue, every decade or so we get bored, change everything and throw the baby out with the bathwater :(
14:49:27
mseddon
I'm somewhat biased, I work a lot in web development, and the churn there is insane.
14:54:18
beach
mseddon: I don't care so much about individuals who use whatever language they like for their own private projects. My talks are about ignorant decision makes who gamble with the future of the company they work for, and therefore also with the future of their staff.
14:57:06
beach
That one or his/her project leaders. I frequently see CTOs in software development who know nothing about software development, and certainly nothing about programming languages.
14:59:55
beach
I hear things like "let's choose Java because all our developers know it already", which really means that "the cost of training our developers in a different language, or of hiring developers for a better language is known to be higher than the loss of productivity from choosing Java".
15:01:06
beach
And I hear "let's choose C++, because we need all the speed we can get", which means "we are willing to spend an arbitrary amount of additional development and maintenance cost, for the tiniest speed improvement".
15:01:46
p_l
the java quote is often untrue - as in, there's non-trivial chance the developers know more and would be willing to use more