This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-09-17
Channels
- # 100-days-of-code (4)
- # announcements (4)
- # aws (2)
- # beginners (88)
- # cider (1)
- # cljsrn (9)
- # clojure (126)
- # clojure-conj (4)
- # clojure-dev (8)
- # clojure-greece (1)
- # clojure-italy (37)
- # clojure-nl (3)
- # clojure-spec (13)
- # clojure-uk (91)
- # clojurescript (392)
- # clojurewerkz (1)
- # clojutre (10)
- # core-async (6)
- # cursive (5)
- # data-science (1)
- # datomic (41)
- # emacs (21)
- # events (1)
- # figwheel-main (52)
- # fulcro (2)
- # hyperfiddle (4)
- # jobs (3)
- # jobs-discuss (9)
- # luminus (3)
- # lumo (9)
- # mount (1)
- # nyc (1)
- # off-topic (73)
- # other-languages (6)
- # pedestal (8)
- # portkey (2)
- # re-frame (9)
- # reagent (8)
- # rum (17)
- # shadow-cljs (38)
- # sql (19)
- # tools-deps (18)
- # yada (4)
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).
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
going to https://pepl.io/admin.html shows you the basic interface. Super simple.
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
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
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.
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
Oh, and one cool thing is this re-view incept
component that allows you to embed views with editors within views with editors, recursively.
So it allows you to build a custom view which enables a user to build an even more custom view
@denisgrebennicov I recently installed SBCL with brew
But SBCL just does compiler improvements, right. No new features added to the languages.
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.fingerhut sounds crazy 😲
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.
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 😄
Dunno, I consider it so powerful. Just 've seen this lately https://github.com/Wukix/LambdaLite 250 lines with SQL like syntax. Pretty fancy
@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.
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.
Compared to Haskell/PureScript learning Clojure is not that hard. There’s much less to learn.
I wouldn't say there is soooo much to learn, but rather being able to use those tools to write good code takes time
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.
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
@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 🙂).
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).
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)
Well, there are some very successful clojure companies out there and they are vocal about the advantages
Dismissing Clojure would be silly/wrong, but it being a 'competitive advantage' is bit of a myth IMO, that was my point
https://blogs.unity3d.com/2018/09/17/webassembly-load-times-and-performance/ some news on unity3d wasm performance testing
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.
I just mean that it is at hand, within reach, and I know how to utilize it to get the effect.
This is experience factor. You can say the same about any technology after using it for a several amount of time
Another possible competitive advantage is, for example, outstanding customer support. Much, much harder to build.
What other language has such a cohesive unified succession model? https://github.com/clojure/clojure-site/issues/188
Trying to reason about changes over long periods or distances, outside of a unified succession model, is a risk, long term.
@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.
Only for me personally perhaps, as an employee in a job market, but not for the business.
@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.
Note the "M" rather than "G". not a typo.
@andy.fingerhut what does this have to do with CL?
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.
One joke about Emacs was that it was an acronym that meant "eight megabytes and constantly swapping".
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.
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...
@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?
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.
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.
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.
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 🙂
Manual memory management combined with mutability means tons of incidental complexity.
It amazes me that Linux works anywhere near as well as it does 🙂
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.