Fork me on GitHub
#off-topic
<
2018-09-17
>
andy.fingerhut00:09:30

Out of curiosity, I tried downloading the source code for sbcl-1.4.11 to my OS X 10.12.6 machine, and used the MacPorts installation of sbcl-1.4.9 to build it, then run its fairly large set of built-in tests. It built with no problems, and passed all of the tests that were not disabled (which are only a handful of them, for known issues).

👍 4
john00:09:36

So it looks like github is still provisioning the ssl cert on https://pepl.io but you can check the code for the pepl thing here: https://github.com/johnmn3/johnmn3. It's not finished yet obviously. The code is mostly a dump of javascript examples of interacting with github, online, so I need to convert all the stateful code to functional and clean up a bunch of it. Then I'll put a more forkable thing up on a repo called pepl

john00:09:32

going to https://pepl.io/admin.html shows you the basic interface. Super simple.

john00:09:45

You can't yet make new posts either

john00:09:52

I haven't figured out the web auth flow yet either, so you for now you gotta spin up an oauth app and generate a client-id and client-secret from your github developer settings

john00:09:07

And, with the project forked into your github account, you can access the admin page and put in your credentials and it will do the pull push jazz

john00:09:09

The live editing thing is finicky when trying to write a large blog post. The wrong code can wipe out your whole react interface and you gotta reload. So it'd be nice to smooth that out. Debounce for sure. But perhaps have a 'eval on ctrl-s' mode.

john00:09:11

If I can get it into a more usable spot over the next few weeks, I'll probably put a sticker on it, call it an alpha and put it up in the announcements

john00:09:40

Routing is on the roadmap too

john01:09:38

Oh, and one cool thing is this re-view incept component that allows you to embed views with editors within views with editors, recursively.

john01:09:00

So it allows you to build a custom view which enables a user to build an even more custom view

borkdude07:09:32

@denisgrebennicov I recently installed SBCL with brew

Denis G07:09:01

yeah, just checked today in the morning the SBCL version in brew. It's the latest

Denis G07:09:14

But SBCL just does compiler improvements, right. No new features added to the languages.

Denis G07:09:21

It's just unusual to here that the language is complete

Denis G07:09:41

WHereby other languages release new features every other year ...

andy.fingerhut08:09:35

It is true in many cases (not all) that features that other languages have added over the last several decades, Common Lisp had in the 1980's.

andy.fingerhut08:09:04

It is a language that grew up before POSIX, before Unicode, before Linux, Perl, Python, and Ruby existed (or was getting the final touches on its ANSI standard when they were only a few years old), so I'm not saying it is the be-all of programming languages. It is impressive what it has, though. These days, I'd say Python makes a fairly decent dynamic language, and it is much easier to find help for it, but performance of pure Python code (when it isn't actually a thin wrapper around a C/C++ library) is not as good. It doesn't have default immutable data structures like Clojure does, so has a significantly different "flavor" than Clojure does.

Denis G08:09:40

But if CL had already all of those features in the 80s, why it didn't gain its popularity. I can not imagine picking either CL or Java 1 or something 😄

borkdude08:09:17

for the same reason JS is so popular and ClojureScript is not?

borkdude08:09:45

superficial familiarity

borkdude08:09:32

and also some languages got lucky, e.g. JS is shipped with every browser

☝️ 4
borkdude08:09:39

Java was pushed heavily by Sun

Denis G08:09:08

Dunno, I consider it so powerful. Just 've seen this lately https://github.com/Wukix/LambdaLite 250 lines with SQL like syntax. Pretty fancy

borkdude08:09:24

often the “best” solution isn’t the most popular solution.

borkdude08:09:13

one reason could be that Common Lisp was too much associated with the AI winter.

Denis G08:09:27

@borkdude when it comes to ClojureScript being popular. THere are a lot of alternatives nowadays, Elm is the famous one. PureScript, ReasonML, Fabel (F# to JS), etc.

borkdude08:09:59

true, but JS is still way more popular

Denis G08:09:23

picard-facepalm 😄 😄 😄

Denis G08:09:07

In today’s environment, undergrads have less focus on functional programming, and it is actually not required to get a degree to find a programming job. However, functional programming as in Clojure requires too much effort upfront to understand the core concepts and put them to good use. It just takes a bit longer (a few months) to get up to speed and start writing good Clojure/script code and making something substantial. Therefore, all the 10-year-old programmers may find it harder, entrepreneurs may find it harder, and management in large companies may not want to invest in it. Therefore, it will remain as a great competitive advantage of small startups that choose to use it. And that’s not so bad.

borkdude08:09:09

Compared to Haskell/PureScript learning Clojure is not that hard. There’s much less to learn.

Denis G08:09:51

I wouldn't say there is soooo much to learn, but rather being able to use those tools to write good code takes time

henrik10:09:35

One of the main reasons I’m betting on Clojure is that I know that there are a lot of others who won’t. You’d be hard pressed to find a competitive advantage that comes as cheaply.

👆 12
vemv10:09:50

I recall that point from Paul Graham dragging me into lisp but I'm not sure I see it so optimistically anymore. I've yet to see a '10x' clojure-centric stack (not that it's impossible...) Low bug-count or complexity are certainly nice, but I don't think that makes a company stand out over the other (modulo extreme cases). Product-market fit, sales or even graphic design matter more to the layman

samedhi14:09:27

@vemv 1) Product market fit (if you are at that stage) 2) Miscommunications between the stakeholder and the developers 3) Misunderstanding of what the customer needs are still the major threats/errors made during software engineering (even in lisp 🙂).

vemv14:09:17

Fully agreed!

samedhi14:09:06

Just better to be in a language that tends to allow you to redirect efforts and change requirements more easily; plus is more fun (imho).

vemv14:09:27

Whether that language is Clojure is not a certainty. Without a lot of money I'd tend to push for Rails or similar. Clojure development tends to get caught up in technical intricacies (e.g.: wiring up a webapp, developing some custom lib)

mpenet14:09:53

Well, there are some very successful clojure companies out there and they are vocal about the advantages

mpenet14:09:21

then ymmv of course, depends on the domain etc etc

vemv14:09:10

I'd say it's a cost/benefit tradeoff 🙂

vemv14:09:13

Dismissing Clojure would be silly/wrong, but it being a 'competitive advantage' is bit of a myth IMO, that was my point

henrik14:09:34

A competitive advantage doesn’t automatically eliminate all other concerns. All concerns have to be good enough or better. There are many possible competitive advantages depending on your business. I consider Clojure a “free” advantage, in addition to the others.

henrik14:09:11

(It obviously isn’t completely free)

henrik14:09:20

I just mean that it is at hand, within reach, and I know how to utilize it to get the effect.

✌️ 4
Denis G14:09:49

This is experience factor. You can say the same about any technology after using it for a several amount of time

henrik14:09:51

Another possible competitive advantage is, for example, outstanding customer support. Much, much harder to build.

john14:09:39

What other language has such a cohesive unified succession model? https://github.com/clojure/clojure-site/issues/188

john14:09:33

Trying to reason about changes over long periods or distances, outside of a unified succession model, is a risk, long term.

henrik15:09:05

@denisgrebennicov True, but if I had intimate familiarity with a less excellent, and more widely utilized, tool, it would still not yield a competitive advantage.

henrik15:09:34

Only for me personally perhaps, as an employee in a job market, but not for the business.

andy.fingerhut19:09:14

@denisgrebennicov Regarding Common Lisp not taking over the world, at least one factor (not the only one): In 1990 I had a Sun4 workstation with 16 Mbytes of RAM that cost the University probably $10,000. and in 1994 I bought a personal Intel desktop machine with 16 Mbytes of RAM that I ran Linux on for about $2,500.

andy.fingerhut19:09:32

Note the "M" rather than "G". not a typo.

borkdude19:09:57

@andy.fingerhut what does this have to do with CL?

andy.fingerhut19:09:10

People then were much more sensitive to memory footprint of programs, and it wasn't difficult to believe that you could have better control over your memory footprint with languages like C or C++ vs. Lisp.

andy.fingerhut19:09:38

One joke about Emacs was that it was an acronym that meant "eight megabytes and constantly swapping".

andy.fingerhut19:09:57

Emacs isn't written in Common Lisp, but mostly Emacs Lisp, but now anybody writing server or desktop code coughs and uses 8 megabytes without thinking twice.

aisamu19:09:41

On a tangent (this is off-topic after all) but on that same line of reasoning - I still remember people complaining that smalltalk was unusable and wasteful with its image-based development/deployment...

borkdude19:09:39

@andy.fingerhut yes, good point, that may have been a good reason for Lisps impopularity. Isn’t that what “lispers know the value of everything, but the cost of nothing” was about?

andy.fingerhut20:09:21

That $2,500 personal machine was also running single core at 66 MHz, so processor cycles were also a place where it was easy for people to believe that lower level languages could give them more efficient use of that sometimes-scarce resource.

andy.fingerhut20:09:25

I think sometimes those concerns of the implementation cost were overblown, but the dramatic continuation of reducing costs of processor cycles, memory, and disk over decades have a way of changing one's evaluation of these tradeoffs.

andy.fingerhut20:09:14

I work at Cisco Systems, and it is amazing to me how much code is still developed in C there, but large code bases tend to have a lot of inertia, too.

borkdude20:09:05

which language are you using there?

andy.fingerhut20:09:42

The last couple of years I have been in an engineering role where mostly I deal with prototyping of various things, so for tiny code I can write a little bit of Clojure that no one else ever sees, or a medium amount of Python that a few other people do. I have been in multi-year roles dealing with heaps of C code, and am trying to avoid doing that again, unless the pay is tremendous 🙂

andy.fingerhut20:09:04

Manual memory management combined with mutability means tons of incidental complexity.

andy.fingerhut20:09:24

It amazes me that Linux works anywhere near as well as it does 🙂

hubert20:09:44

As Donald Knuth once said "Premature optimization is the root of all evil" 😉

spieden20:09:39

it boggles my mind how much linux kernel devs must need to hold in their heads

✔️ 4
andy.fingerhut20:09:16

It isn't premature optimization if technology X gets a working product in N months, but technology Y only gets a working product M years later, where M is unknown 🙂 But those are difficult things to quantity when you are nearer the edge.

borkdude20:09:03

maybe Rust will make a big change there?