Earlier quoted context omitted.
Seeing Common Lisp fans arguing against Clojure fans is funny since your market share combined is insignificant compared with the mainstream choices. You should learn from each other and grow that pie together. I also don't agree with you. Intuitively Lisp might be a secret weapon for startups, but not for open source where the communities of the mainstream choices are more productive, simply because of popularity. J…
> Intuitively Lisp might be a secret weapon for startups, but not for open source > where the communities of the mainstream choices are more productive, simply because > of popularity Open source is not a popularity contest. In fact, open source, and specially free and libre software, is a great place for leftfield technologies to flourish. In fact, Lisp had a place in free software before Github even existed, with v…
Lisp is still a secret weapon
131–140 of 145 posts
Re: Lisp is still a secret weapon
#132Earlier quoted context omitted.
Heretical or not you are dead wrong. Don't think so? Go program in Forth or Assembler instead of your current main language for a while and get back to me. There would have been no reason to invent any HLL or even assembler if you were correct. Put aside your ruby and try to do the same work in vanilla C and get back to me.
Forth should not be in this list, it is a meta-language. It can be quickly turned into something equally or more powerful than you current Blub (pick any, does not matter).
Re: Lisp is still a secret weapon
#133Earlier quoted context omitted.
Forth should not be in this list, it is a meta-language. It can be quickly turned into something equally or more powerful than you current Blub (pick any, does not matter).
"Quickly" without writing tons of Forth code, not. And it still wouldn't match 200.000 npm packages or a million or so for Java.
Re: Lisp is still a secret weapon
#134Earlier quoted context omitted.
That 200k figure isn't very comparable to other languages either as there are a lot of pacakages that just do a tiny thing and a hell if a lot of overlap in packages. While that's got upsides I must admit I prefer one or two relatively complete and stable packages over way more numerically but leas stable complete packages. But I come from a desktop background so I'm spoilt in that regard I guess. I view every additi…
Completely agree. Maintaining a node project is a nightmare job if you rely on any more than a trivial number of packages. The ecosystem is quicksand.
Re: Lisp is still a secret weapon
#135Earlier quoted context omitted.
"Quickly" without writing tons of Forth code, not. And it still wouldn't match 200.000 npm packages or a million or so for Java.
5-6kloc is not "tons", it's just several days worth of work. And then I can build a compliant JavaScript implementation on top of this, in order to be able to parasite on 200k npm packages (actually, did this already).
To buy you what? Not even what the Java SDK has as built-in libs. And 5 kloc in "several days"? I doubt it.
>And then I can build a compliant JavaScript implementation on top of this, in order to be able to parasite on 200k npm packages (actually, did this already).
Link or it didn't happen.
Besides, there's no point in using Forth if you're gonna end up running your stuff in a "compliant JavaScript implementation" (which takes much more than "several days" anyway).
Re: Lisp is still a secret weapon
#136Earlier quoted context omitted.
5-6kloc is not "tons", it's just several days worth of work. And then I can build a compliant JavaScript implementation on top of this, in order to be able to parasite on 200k npm packages (actually, did this already).
> 5-6kloc is not "tons", it's just several days worth of work. To buy you what? Not even what the Java SDK has as built-in libs. And 5 kloc in "several days"? I doubt it. > And then I can build a compliant JavaScript implementation on top of this, in order to be able to parasite on 200k npm packages (actually, did this already). Link or it didn't happen. Besides, there's no point in using Forth if you're gonna end up…
To get a powerful core language on top of which I can build anything in just a couple of hundreds of lines (e.g., a complete JavaScript - in order to get the rest of the libraries for free). Or a JVM. Or .NET CLR. Or whatever else.
> And 5 kloc in "several days"? I doubt it.
I did this as an experiment once. From bare machine code on a new architecture, via a very basic Forth, to Lisp and then C and everything else. Did not take much time to do.
> Link or it didn't happen.
Did not publish it yet for a variety of reasons, but may include this JavaScript compiler in my next code drop soon, stay tuned (see my github).
> Besides, there's no point in using Forth if you're gonna end up running your stuff in a "compliant JavaScript implementation"
The question was that having only Forth would not leave me crippled - I'll get all the power I want in just few days. And this kind of JavaScript implementation is more than just JavaScript. It allows me to use anything coded in JavaScript seamlessly from any other language built on top of the same meta-language.
Re: Lisp is still a secret weapon
#137He didn't sell me on why Lisp is better than any other language? Why would you pick Lisp or Clojure over say Elixir, Scala, or even F#? JT
> Why would you pick Lisp or Clojure over say Elixir, Scala, or even F#? They are all great choices! F# is an excellent choice if you are happy living within the .net ecosystem. I'd highly recommend it if you are a c# dev. Tooling is great. Ecosystem is really good etc. Performance is really good. Elixir? Its a really good option for high concurrency apps. It's based upon Erlang and has access to heavily battle teste…
Re: Lisp is still a secret weapon
#138Earlier quoted context omitted.
The fact I am being downvoted is indicative that I am on to something. Think about it :-)
I think yours is the best response to these sorts of painful-to-read HN threads.
Re: Lisp is still a secret weapon
#139Earlier quoted context omitted.
But in some languages bloat is a best practice.
It's all about how many adjectives you can get into your class name. e.g. SingletonFactoryAdaptorFacadeProviderEnumerator myClass; With Haskell it is about how big your monad stack is StateT ReaderT WriterT LensifierT MaybeT BeerT (IO Int).
Re: Lisp is still a secret weapon
#140Earlier quoted context omitted.
> and by necessity I have to disentangle the syntax of the language from the essence of the problem. Doing that is why programmers prefer different languages, some language allow that to be easier than others do. Some language allow a much more direct expression of the essence of the problem. > Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation. Sure it does,…
In my experience, the more interesting reasons to choose languages come from the "platform and ecosystem" categories rather than syntax. Lua: It has clean, clear syntax but its real value is the implementation, which is geared towards use as an embedded language. Javascript: The language isn't bad but were it not for being the browser scripting language it never would have gotten so popular and tools like node.js pro…
I agree, but that doesn't have anything to do with what I said. I didn't say anything about choosing a language for a particular job, I said what makes programmers prefer a language which is very much syntax.
> Javascript: The language isn't bad but were it not for being the browser scripting language it never would have gotten so popular and tools like node.js probably wouldn't even exist.
If it were not for being the browser scripting language, it would not exist, so any reasoning beyond what it might have been otherwise is fallacious as it would not have been at all.
> Java: Native language on the powerful JVM.
Nope, portability across platforms made it popular.
> But picking the right language for a job usually requires going beyond the syntax.
Not disputed, but still unrelated to my point which is about syntax. I'm discussing syntax, it's off topic to and rude to tell me not to discuss syntax which is basically what you're doing.