Knowing that certain powerful features of programming languages can be used to create unmaintanable code, do we ban those features or do we try to harness them by using a disciplined approach to software design?
Specifically with regard to meta programming, I think we have seen all that can happen several times over.
If you have those features within the programming language they tend to get overused. If you don't have them within the programming language, they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises.
The architects will be constrained by Java, but they can use it nonetheless. And instead of metaprogramming with Lisp they can metaprogram with humans. You'll need them anyway, as the application grows, and like this they get to know the code better, since they write it.
can confirm, if you can't metaprogram in the language, you will at some point write external code generators and such... Metaprogramming is just the most common programming "task", avoiding repetition, applied to itself.
I don't have any example were the disciplined approached worked so I would agree with the first option. People overused every single bad feature, here it's Lisp but it's the same in Php, Perl, Javascript or Python.
Discipline never works unless it's enforced. So the only hope is to figure out "less powerful" versions of those features that cover all their important use cases without permitting unmaintainable code. Fortunately, modern programming language design has gotten pretty good at that: 95% of the killer use cases you'd see as macro examples in Lisp advocacy 20 years ago are now ordinary, standard-ish programming language features.
> If you have those features within the programming language they tend to get overused. If you don't have them within the programming language, they get tacked on in some inconsistent, half-assed way as soon as the need for frameworks, DSLs or sophisiticated configuration arises.
That's a possible failure mode, but we've been pretty good at moving away from it IME. The best modern languages do manage to walk the fine line between a language that's too constrained to do anything in without some magic addon and a language that's unmaintainably flexible in the language proper.
[1] https://www.cise.ufl.edu/~manuel/obfuscate/obfuscate.html
Only a smart programmer can write Lisp. The popularity is proportional to how much cognitive capability requirements of the language. The story is the same with Haskell.
Php, javascript, java, C# : all very popular.
Haskell, clojure, Lisp, F#, APL (and derivatives): all very niche, and requires some knowledge that one might consider "higher level" than required for the former list.
I don't know if it is fair to say that Lisp meta-programming is more core to the language than CPP is to C.
The bigger problem here is the number of programmers have increased disproportionately over the years. For that alone reason technologies had to be dumbed down to a point where anybody could use it.
If programming kept its original ethos, it would suffer the same problems one suffers taking a subject like Math mainstream.
But the real problem here is just starting now. You now have a whole generation full of masses of programmers who only do XML/JSON parsing, talking to HTTP interfaces and doing HTML and doing nothing more. This is like people doing basic algebra whole life. Eventually you won't get much out of this sort of practice.
At some point in time, to not max out the value generated by a system you have to up the level of the game, and that would come at a painful task of having to retrain entire generations of programmers which neither will be easy, and in many people's case it won't be possible.
Already languages like Java have shown their limits. To build anything meaningful you need large frameworks, with crazy dependency graphs, to manage which you need one another framework(DI). And with all that you barely get to do the ordinary stuff.
So eventually you would have only delayed the use of something like FP, not entirely eliminated it.
>>There is little demand for programming languages that are hard to maintain.
Java applications with 100 classes to post to REST interfaces will eventually suffer the same fate.
'Maintainability' is a very subjective term.
>>A working program lasts decades
Not true anymore. This was true pre dot com days. Thanks to all this agile processes and 'fail fast' culture. Code bases have very little life these days.
>>LISP is dead-end technology that will forever keep being brought up as its temptations are irresistible to some.
The success of Clojure means this is totally false.
The lisp community refused, and has a serious elitist taste that you can even feel in the comments.
I'm ok with it, but you must accept the price of this is peopme leaving, or not comming in the first place.
To me it seems an acceptable deal. Plus you can't have your cake eat it.
The thing with languages like Python. They will lower the bar for entry, but they will keep you at the beginner stage all along the stay.
That's OK. Programming isn't a monolith, we already have several layers of programmers based on the complexity of the task they solve. So Lisp will have its own place, so will languages like Haskell and F#. Its also upto the programmer to decide at which layers they like to work.
It's a language with a gentle learning curve, yes, but a long one.
Don't confuse the fact it gives you quick productivity with being shallow.
Lisp is espacially deep, so i won't dare to compare the 2, but python has way more under the belt that it's reputation. Which is great : only learn what you need at the moment you need it. Then curioisity can take you ahead if you wish.
A humongous percentage of developers are paid a lot to paint houses reliably: https://www.joelonsoftware.com/2002/05/06/five-worlds/ (internal software, consultingware)
In the software world, you either level up your tech skills or you level up your domain knowledge skills. Both are lucrative career paths. The second one can be easily covered with Java and it will continue to be so for the foreseeable future.
But If learned programming, using C based languages, and that journey was done, I might as well go an extra mile and explore further.
Nothing bad ever happened by gaining more knowledge.
Have you ever seen so-called academic code? If your developers are PhDs without a programming background, you're bound to get programs that reflect the complexity of their own throught process plus the subject they are dealing with. I don't think encouraging that through something as unbound as Lisp is a good idea, as much as I love how unbound Lisp is.
Python probably hits a sweet spot in this regard.
It's possible to write horrible python code. But it's way harder
Even without an editor, you are forced to indent. You can't use macro or make huge anonymous functions. The whole language is designed around readability.
Like in Python, we have context managers (with statements), they're cool but we can't do much inside them. I wanted to use them to add logs to a list and automatically return it from my api. I couldn't, I had to do that manually everywhere.
Now enters a new developer. In Python he would learn the base style, function names, the use of our custom context manager plus the need to manually feed and return the list of logs. In Lisp he would learn that our context manager (a macro) handles the logs.
---
This thread gets comparisons to Python, so let's enlarge the comparison spectrum: Lisp has a better REPL (enjoy ipython ? You'll love a Lisp REPL !), better type inference, it is a compiled language, making it a breeze to build an executable of your web app and deploy it to your server, a better object system (method combination, polymorphism, methods not bound to classes,…), Lisp is stable,…
I think I see the problem.
100 line functions, aside from methods in DAOs, are a code smell in any language.
Being able to apply the resulting work to the real world is very hard, because for a programmer - you have to package it up in a way that's easily digestible to people who don't want to have to go through the process of reinventing the wheel from scratch in order to understand it (or just don't have the time to).
Lisp doesn't have to be complicated with a billion bells and whistles to be good lisp code. If you approach learning it from there, you build your own, don't have to compare it to PhD level research. It might one day get to that point, where no one can understand or wants to understand what you've created, but that's the other side - the isolation that comes with being an academic.
The subtlety here is that there is the complexity inherent to the problem domain, which is what you are referring to, and code complexity that arises from translating that complexity to a programming context.
Environments like SciPy, Matlab, R, and Julia get rid of a lot of the latter while still forcing certain conventions to follow that make the code easier to read for outsiders, leaving the complexity of the algorithm itself.
And I probably should have used Julia instead of Python as an example, since it aims and IMO succeeds as a "goldilocks" language that combines a lot of great ideas from all aforementioned languages plus Lisp[0]. IIRC, it is sometimes jokingly referred to as "secretly a Lisp" because part of the compiler is writting in... I think Scheme?
[0] https://docs.julialang.org/en/release-0.4/manual/metaprogram...
Femtolisp, created by Jeff Bezanson who is also a co-creator of Julia.
and
>>Python probably hits a sweet spot in this regard.
Willing to learn more on how Python magically converts PhD level quantum mechanics, and related Math to easily understandable stuff.
Also Im all ears, please explain to me how the crappiest and the most competent programmers all become same by the mere use of Python.
Well yeah but guns make it much easier.
The guys says he just wants a language where he and his team can be productive. This. 1000x this. Ranters gonna rant, haters gonna hate, but productive people will use whatever floats their boat. For me it's clojure lately. I don't need to convince anyone that 'X' is better than 'Y'. If a new paradigm comes along (actors) that proves valuable, I hope that my language can assimilate it (quasar/pulsar). Otherwise I'm happy.
Besides, in today's startup economy, we're lucky if a company lasts months, nevermind about decades.
As a manager I would not want such orchids as we call em in German. What if this "rock star" leaves the team? What if we want to bring in more team members? Who pays for the development of these dev tools? After all we are not payed to write code but to solve problems- a fact devs like to forget. Do they really pay for themselves in therms of savings as suggested by the dev?
I don't claim that this questions were not raised and answered, but that from a strategic point of view not the coolest and shiniest toys and concepts may make the most sense.
To "just" be productive you need a huge library/tool ecosystem that, realistically, only a handful of languages are ever going to have at any point in time. Particularly if you want your language to make use of the possibilities that GUIs offer. I love Scala and find its IDE support to be one of its great strengths, but even so it's noticeably behind what you get in Java or C#. And that's a top-20 language.
As for clojure, I have yet to find an environment as good as emacs+cider+nrepl.
My point is quite the opposite: its IDEs are a lot better than you'll find for many languages. On paper Haskell should be a better language than Scala, but you don't see anything comparable to your examples, and I think the tool situation has a lot to do with that. So popularity ends up being very important.
I agree in general, but it's not just whatever floats their boat. Every real project has its yak-shaving aspects. Productive people pick languages (plus libraries and ecosystems) that will handle for them as much of the yak-shaving as possible, leaving them free to work on the problem they're actually trying to solve.
Edit: Actually, I seem to remember that this was how I learned about reader macros and I went on to over-enthusiastically (ab)use them myself....
Methinks that lisp value is exploratory, when you want to go crazy deep, you use it to mold every bit of the language as you want and try paradigms/principles.
ML or Haskell are also used a lot there but I think it requires a bit more apriori planning (separate grammar / semantics, typing, denotational mindset). Whereas lisp is more hack it until you make it.
[1] and if you look Dave Beazley fantastic video talks about "abusing" python metalevel, and compare it to CLOS you will find the difference to be more hard to discern.
- http://lisp-lang.org/success/ (pgloader was rewritten from python)
- https://github.com/azzamsa/awesome-lisp-companies
Besides what's call Lisp in the Tiobe index(https://www.tiobe.com/tiobe-index/) is ranked 27, before D, Clojure, Lua, Erlang, Rust, Julia…
And I find Lisp programs great to maintain: the language is stable, the ecosystem too. Python programs on the contrary are a chore to maintain, even after only 2 years.
https://news.ycombinator.com/item?id=17128977
I don't know what's the worst. That you can't help it or that you won't ever recognize you have a problem.
Unfortunaly there is no Lisp Anonymous, so people leave the language. Shame since it's a fantastic tech.
> I don't know what's the worst. That you can't help it or that you won't ever recognize you have a problem.
Anyone can write bad code. Lisp certainly makes it easier, I won't deny it. And no, I don't have a problem, thank you.
> I don't have a problem
If only people were homoiconic like LISP, they might be better at reflection.
But with some continuity and a carefully crafted own little world, everybody on the team soon chooses voluntarily to speak in the terms of that world, because it is a world well suited to the problem at hand.
Also they don't apply to online open source projects and tutorials.
Now you encounter custom syntax. It will not be clear it's custom first as you have no import path. Maybe it's a variant you didn't know about. Maybe it's part of this particular lisp flavor, after all there are so many.
You google it, but it's hard to google syntax so you are not quite sure that no result mean it's custom, impossible to search or just an obscure feature of lisp. After all there are many too.
So you try to decypher the syntax. But there is no contract for it like for a function. No unique entry point and output. It could be doing anything.
Now wihtout an import path you are on a fun hunt for its possible definition with grep.
When you are finally reaching it, it will be 50+ lines of dark magic you now have to decipher because syntax is hard and not trivial code makes awesome features.
In some lisp shops it works because you have three 10x programmers with years of lisp experience working in the same office. In that particular configuration, lisp is cataliser to this great potential, with xp and communication compensating the rest.
But the world is not solely revolving around this perfect combo.
Actually, in the case of CLOS all kinds of magical things can be happening in what looks like a simple function call.
This can be wonderful or terrible depending on your perspective.
In Slime, use M-. and go to the definition of the thing at point.
"without an import path" ? In CL at least we can very well do the equivalent of "from foo import bar".
> This is why after 50 years it is still a niche language
where "This" is either the REPL or macros, which they do not specify.
It's just as easy for me to speculate that Lisp isn't popular because money talks:
- You have an idea for a piece of software and create a start-up.
-You hire competent Lisp programmers to write that software. Since they're rare, they're expensive.
-The start-up grows because the idea was good and the software works, and somewhere along the line someone sees that more money can be made by cutting expenses on development.
- They shop around and find some outsourcing party that claims to write Lisp cheaper.
- They outsource development, but the software goes down the drain. "Lisp" is now the problem, according to the new developers. But costs are down, growth is still continuing, and they got rid of the weird people who made fun of their Gucci tie.
- People cash out, and on advice of the new developers stuff gets rewritten in the popular language of the day.
- Stuff muddles on for some time, until everything comes crashing down. The cycle starts anew, except now it's clear for everyone involved: don't bother with the software, focus on growth, and in case of doubt:
Blame Lisp!
So yeah, that's my "Why isn't Lisp more popular?" hypothesis: modern software for start-ups is about enabling growth, not quality.
And without further substantiating it's just as valid as blaming it on the "ability to self-modify."
> It makes lisp a terrible experience for beginers.
That might be true.
Gucci ties will always try to outsource, and it will often lead to this, lisp or not.
replace it with Haskell, Ocaml, probably Erlang, and it would probably work:
Why is language X still not popular after Y years?
Because quality and good practice are expensive.
Disregarding its arrogance, the statement is just false :)
It implies nothing of the sort.
> quality and good practice are expensive.
That's the statement. If that implies to you that it's impossible to achieve quality and good practice in any but the aforementioned languages, feel free to do so.
> :)
:)
> a terrible experience for beginers.
Start with your own stuff ;)
Lisp makes it easy to shape a sub-language to fit your own head well. The problem is, few others can figure out YOUR head. Communication conventions are not always pretty or efficient, but they work because they are conventions. If you place parsimony (compact abstractions) above inter-human communication, then all you get is isolated parsimony.
The better embedded languages in Lisp often follow conventions: see for example CLOS and the various conventions it follows from naming to integration.
The actual problem is that defining sublanguages for most developers is not something they have learned. The result is a multitude of languages for similar tasks with their own infrastructure. For many programmers it is normal to wait for new language constructs for several years - while they work around this by combining language built-in constructs (extreme: creating lots of bloat - see Java), by using preprocessors (upto transpilers of different languages - see Java and Javascript for languages transpiling to those).
There is some complexity in Lisp providing features for embedding languages.
But there is also complexity in working around that with languages not very good in embedding. See for example Clojure, a language which provides functional programming idioms on top of Java - the integration is great - but many developers are not satisfied about the integration when it comes to debugging - see the complexity for example of stack traces in a layered language design.
I would say that the operator voodoo of Haskell is worse, and that is coming from someone that uses Haskell on a daily basis.
Modern Vanilla JS written in 2018 has the same backwards compatibility guarantees, it's extremely likely that you'll be able to run it in 2038.
Once you add Babel, React & co, all bets are off...
That's simply not true. I think the only reason that Lisp is unpopular is the syntax, which is unfortunate because it's the syntax which is the source of all its power. As for why the syntax itself is so unpopular, sometimes I wonder if irregular syntax really does help comprehension (i.e., that having {}*&^%$#@! helps as a kind of visual shorthand), but most of the time I think it's really just unfamiliarity.
Can you point me to some lisp code that's completely bonkers and which most people are incapable of understanding?