Fork me on GitHub
#jobs-discuss
<
2022-02-09
>
ignorabilis17:02:02

@santanu.chakrabarti - to add to @hiskennyness’s response - basically because of Lisps curse - The power of Lisp is its own worst enemy. You can read the whole thing here - http://www.winestockwebdesign.com/Essays/Lisp_Curse.html, but it's basically this - harder languages require people to work together. And being 🐑 also feels safer. On the contrary, Lisp did not build that community because a dev could single-handedly do 90% of the development. But that means people had to be more courageous to do things alone... And also some people preferred to be special-snoflake-stars, etc.

👍 2
cp4n17:02:45

Very interesting read. Thanks for sharing

respatialized19:02:55

While I don't deny that there's some insight in this essay, every time I read it I have to ask myself how seriously to take the PL observations of someone whose public portfolio consists of stuff like: https://codepen.io/winestock/pen/Pazpmm

Santanu Chakrabarti06:02:02

@U8XSMEQS0 Thanks for sharing the article. Well I don't know why but LISP seems like my "lost love" to whom I am trying to return again. And I am enjoying it. I was busy with it recently so couldn't be online in Slack for some days. Here is the result: https://programmerscratchpad.wordpress.com/2022/02/11/configuring-emacs-for-common-lisp/. Also from my childhood I have this peculiar tendency of liking a lonely journey 🙂. This thread has some really interesting inputs to ponder on.

👏 1
Ian Fernandez23:05:04

Common Lisp in fact was very difficult to maintain accross many idioms, everyone built their own languages with macros and their DSL, every library had 70% of use cases covered but no interop between lib. Joining the idea of "lone wolf hacker mindset" and people not building tests around the stuff should be some of the "Lisp Social problems"

kennytilton00:05:29

Some of us had quite good luck with Common Lisp, including finding libraries when needed. And as with the confusion in the Lisp Curse theme, macros and DSLs are precisely what make Lisp stand out. As Paul Graham said, a developer can "build CL up" to be the perfect language for the domain on which they are working. The name of that work, "On Lisp", methinks was about just that, building a better language for the job on top of lisp. Right now I am deeply immersed in macros in ClojureDart, wrapping Flutter in kindler, gentler syntax that happens also to provide fine-grained reactivity. https://github.com/kennytilton/mxflutter A comparison of Dart source, CLJD source, and mxFlutter source will make clear what can be accomplished with DSLs.

adi18:02:07

I find this bit of folklore interesting, because that "curse" appears to exist wherever I look, precisely because it is not technological but cultural. Anyone who's constructing framework islands, or type system superstructures, or microservice mazes, or any number of such cases.

👍 1
1
annarcana18:02:49

It also never made much economic sense to me. Surely from an employer's point of view, it should be good if you can get one guy to do the work of ten without breaking any labor laws. that's literally what we build robots for.

Aron18:02:27

never heard of digital taylorism? 🙂

Santanu Chakrabarti06:02:02

@U0VQ4N5EE This is a new term for me. Obviously I shall Google it but can you please give a brief introduction to it?

Aron07:02:44

It's scientific management for the digital era...

👍 1
mattly18:02:12

organizationally having “the one guy who can do the work of ten” is a double-edged sword

☝️ 1
R.A. Porter18:02:15

1. Iff you can get that one person 2. Iff they don't get hit by a bus 3. Or, if they do get hit by a bus, iff you can replace that one person

☝️ 1
😄 1
annarcana18:02:16

I think the pandemic has rather wonderfully illustrated that many companies in all manner of domains are happy to take that risk 😉

😲 1
Santanu Chakrabarti06:02:18

I don't think I fully understood what you meant to say. Do you think Companies are moving more towards LISP for their softwares?

Aron18:02:58

I don't see that illustrated anywhere

annarcana18:02:34

Maybe not in tech you don't. But admittedly there's less on the line when your entire Chipotle staff walk out, than if your engineering team does

mattly18:02:35

I left a string of jobs where I used clojure to be that guy who could do the work of ten, for a larger company doing go/javascript stuff, and while I’ve done some one-off projects here with clojure/script, for anything that we even think about turning into something we rely upon to help run the business we have to come up with continuity plans around team members leaving

👍 1
jeff.terrell20:02:28

IIRC the Lisp Curse is not just about continuity, it's also about the complexity of what you're trying to create, and how fast you're wanting to create it. A team of 10 good programmers with decent communication patterns can usually outperform a lone dev, no matter how good they are. For really high complexity stuff, you need hundreds or thousands of devs, and a lone dev can't approach that—even with Clojure. simple_smile

adi04:02:45

> For really high complexity stuff, you need hundreds or thousands of devs I think complex systems is where it gets really interesting. Here's my premise: • Complexity is nonlinear and compounding. • People who create software systems are fundamentally a part of said systems. Conway's law dominates. • Software is leverage. • Culture, design, and dominant architectures govern everything. If a team manages to address only the right kinds of complexity from the get go, and manages to retain the discipline over the long run, the software leverage feedback + non-linearities tend to favour massive outcomes from small tight-knit groups. My anecdotal observation is that team performance and outcomes are bimodal due to the difficulty of staying on such a disciplined path. Groups that lose the art of taming complexity require multiples (or even orders or magnitude) more to achieve what another group ruthlessly focused on simplicity can achieve. In picture terms, I visualise it like this (more https://www.evalapply.org/posts/systems-scale-value/#model-a-picture-is-worth-a-1-000-points):

adi04:02:15

Aaron Hsu's https://github.com/Co-dfns/Co-dfns is to me one of the most stunning examples of "Design + Architecture dominates all". This slide from Raph Levien's talk "https://www.youtube.com/watch?v=eqkAaplKBc4" illustrates the contrast (a single person's output v/s that of rather large teams). Aaron's approach to "data parallel" computing frames the problem in such a way that a really compact https://news.ycombinator.com/item?id=13797797 solution falls out of it.

2
thanks3 1
👀 1
wow 1
Aron07:02:53

The whole point of differentiating complex from complicated is to point out that complex systems' behavior do not follow linear causality, but dispositionality. It's not reductionist, not aggregative. You have to manage the dispositions as a whole.

2
bherrmann01:02:27

Those ascii graphs are cool.

adi03:02:37

😀 thanks. Courtesy Emacs Artist mode. I often use artist plus DITAA for diagrams. This is a nice little demo: https://www.youtube.com/watch?v=cIuX87Xo8Fc

vemv20:02:22

"10x" sadly became a misunderstood meme but I still find it a useful notion. While I can't consistently outperform a peer ten-fold, a skilled programmer can certainly have "10x moments" here and there. e.g. one can devise macros, mechanisms, tools, etc that can make a codebase drastically simpler to work with. Everyone in a given team benefits from those.

👍 1
lread20:02:52

and then there’s @borkdude.

babashka 12
nbb 4
sci 4
clj-kondo 4
jet 4
graal-vm 4
borkdude 9
Nick McAvoy20:02:33

> Any idea why Lisp/Common Lisp didn't get used much in commercial software development? Could this be in part an accident of history? Is it possible that Lisp lost out because other languages gained traction, but it didn't have to be that way? History is usually not inevitable, and in general, things could have gone differently than they went. It seems there may be a hidden assumption here that history proves Lisp is inferior for commercial usage, and so we need to work backward from that to a reason for its inferiority. I gave a talk last year where one of the main premises is that because Clojure makes devs more powerful than common alternatives, giving Clojure to your dev team makes them more powerful. https://youtu.be/L9KcoRZcdbc?t=968

👍 1
Santanu Chakrabarti07:02:20

@U01BA210C7K I agree with your argument. Human life like a Heuristic search doesn't always take the best possible route but try to take an optimal route. But Lisp and for that matter Common Lisp has its frustrations, that I am facing too while trying to get back to it. Libraries seem to get tied to very few or single Common Lisp implementation instead of being portable.

adi04:02:45

> For really high complexity stuff, you need hundreds or thousands of devs I think complex systems is where it gets really interesting. Here's my premise: • Complexity is nonlinear and compounding. • People who create software systems are fundamentally a part of said systems. Conway's law dominates. • Software is leverage. • Culture, design, and dominant architectures govern everything. If a team manages to address only the right kinds of complexity from the get go, and manages to retain the discipline over the long run, the software leverage feedback + non-linearities tend to favour massive outcomes from small tight-knit groups. My anecdotal observation is that team performance and outcomes are bimodal due to the difficulty of staying on such a disciplined path. Groups that lose the art of taming complexity require multiples (or even orders or magnitude) more to achieve what another group ruthlessly focused on simplicity can achieve. In picture terms, I visualise it like this (more https://www.evalapply.org/posts/systems-scale-value/#model-a-picture-is-worth-a-1-000-points):

adi04:02:15

Aaron Hsu's https://github.com/Co-dfns/Co-dfns is to me one of the most stunning examples of "Design + Architecture dominates all". This slide from Raph Levien's talk "https://www.youtube.com/watch?v=eqkAaplKBc4" illustrates the contrast (a single person's output v/s that of rather large teams). Aaron's approach to "data parallel" computing frames the problem in such a way that a really compact https://news.ycombinator.com/item?id=13797797 solution falls out of it.

2
thanks3 1
👀 1
wow 1