7 ms·

-- This is prolly the most arrogant opinion I have -- I think if every programmer started using LISP we would have a massive unemployment crisis - since many s

-- This is prolly the most arrogant opinion I have -- I think if every programmer started using LISP we would have a massive unemployment crisis - since many software engineers would lose their jobs - as most are forced ( due to the nature of capitalism ) to sell snake-oil solutions to problems already solved 50-60 years ago. -- I am not a Lisp programmer , so no accusation on smugness pls. I just ended up using Lisp concepts daily when programming terrible languages since that is what the market wants :) # Resume Driven Development

biot 10y ago
What are some examples of problems that are being snake-oiled that were already solved half a century ago?
- kuschku 10y ago
  A lot of things currently done in the javascript world are just people discovering that the "just copy all code into a file" world of things doesn’t work – and so they reinvented modules, after the "kik" debacle, now reinvent namespaces, they reinvent dependency management, etc. Just look at the javascript world, they have enough examples.
  - jonathankoren 10y ago
    This. JavaScript's engineering culture is a dumpster fire of 40 year old bad ideas that the rest of the software community abandoned 40 years ago.
    - neoeldex 10y ago
      It is a language in a constant changing environment. The web today has different requirements than 20 years ago. It's not right to criticize the reimplementation of things in different systems. That has to happen... Paradigms shift, so thus do implementations
      - jonathankoren 10y ago
        That doesn't explain the left-pad debacle, and the apologists defending that anti-pattern. That's a people problem, not a technology problem.
        zaphar 10y ago
        Left pad was both. The ultra small single function library approach prevalent in npm is caused by fundamental limitations of javascript in the browser. The political issues that surfaced it all was a people problem.
        jonathankoren 10y ago
        While the impetus for a left-pad like function is due to a lack of a standard library, that's not what went wrong. Brushing the problem aside as merely a "political issue" shows that you don't understand what went wrong either. 1) The whole culture of bringing in a mass of external dependencies for single specialized functions is to be quite honest rather strange and problematic on it's own. Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. 2) Bringing in an literally an unknown number of external dependencies is dependency hell. How many different left-pads and left-pad-likes do you have? Do you even know? 3) The justification of trivial functions as standalone dependencies is justified as a vetting process. Somehow by pulling in everything separate will improve code quality? No. Fixing bugs improves code quality. Honestly, someone in this very forum justified left-pad as a standalone because it helped "find edge cases." What's the edge case in left pad? There's literally only two edges. -1 and (padtosize - len(num)). On one end you get an undefined, and on the other, your string is wrong. Even if you walk off the entire string, you get another undefined. It's a lesson 1 Intro to Programming problem. 4) Having a bunch of minimum functions makes choosing the right one impossible, or maybe it doesn't matter at all, in which case what's the point. Seriously. I was going to make a remark about "Why not just implement printf?", when a quick google found THREE! printfs on npm (format, sprint, and qprintf.) And then of course there's left pad if all you want is "%03d". 5) The actually source of the left-pad debacle is autoupdating external dependencies from the Internet. This is a horrifically Bad Idea. It was a Bad Idea before the left-pad debacle, and it's a horrifically Bad Idea after the left-pad debacle. And I have no doubt that the javascript community did not learn this lesson. Instead it appears all that was learned was to be scared of trademark claims. Autoupdating dependencies is a Bad Idea because it's how you get bugs. Seriously, if the javascript community simply didn't do this, and instead followed the best practices software engineering practices since literally the dawn of external libraries, then the whole left-pad debacle would have been greatly mitigated. The whole security injection clusterfuck happened because the kid that runs NPM got scared because "code was breaking", of course it's not his code, it's just random code on the Internet, because the javascript community doesn't employ widely implemented best engineering practices. NPM as exploit delivery vector was always there, and it's still there if you don't do proper versioning and vetting of your external libraries. Passing the buck, isn't acceptable. Left-pad was to the greater software engineering community like the scene at the end of Lord of Flies, when the adult finally shows up, looks around at the chaos and says, "What are you guys doing?"
- __s 10y ago
  CRUD. My day job involves maintaining ASP webform sites which are a set of inputs to create compute contracts. Lots of copy pasted code I'm trying to consolidate. Lacks use of generics or ORM or form models
- PeCaN 10y ago
  Most of these are from the late 70s/early 80s, so not quite half a century. Debugging – look at Smalltalk if you don't believe me. Security – Intel i432 didn't sell well, but now we're sure wishing it had. The entire system was built on an object-capability model from the hardware up. The OS and userspace were fully written in Ada. Persistence – System/38 and AS/400 — everything has a persistent address. All pointers are 128-bit (yes... this was designed in the late 70s). Everything is an object and the OS has a built-in database. You can persist anything effortlessly. String processing – Regular expressions are useful; SNOBOL is more readable, more powerful, more efficient, and existed in 1962. Awk is a joke. Declarative programming – I feel like Greenspun's 10th Rule applies at least as much to Prolog as it does to Lisp. The sheer number of cases where embedding a little unification engine dramatically simplifies code is pretty baffling. GUIs – we've almost caught up to the ease of use of the Dynamic Windows system on Symbolics Lisp machines. Concurrency – it amuses me that Go gets so much attention lately when it's just a re-skin of Occam from 1983. Probably more. I feel like i432 and AS/400 in particular were very, very ahead of their time.
  - viraptor 10y ago
    Do you really think a very high level processor was the way to go? It seems like we're just going lower and lower in the stack in the more advanced applications. I mean, on i432 (from what I learned about it) you couldn't even free memory - you were stuck in it's specific instructions, GC, and other elements. It could be an interesting version of a secure execution enclave (like Intel tries to create today), but I'm not sure it would be useful or performant in general processing.
    - sklogic 10y ago
      Tagged memory was definitely a way to go. Would have eliminated most of the security issues we had so far. Luckily, it's slowly making a comeback, see the RISC-V efforts for example.
      - pjmlp 10y ago
        And Intel's MPX. We already had all of that in the early 60's with Lisp and Algol dialects based OSes. Apparently we need to have daily memory corruption CVE's as industry wake-up call.
- tluyben2 10y ago
  Not really 'problems' but some examples of things which did not had to be written over and over; we still do so because it is a) hard to reuse software b) we have no source from others c) snake-oil; we want to make money and just giving them something that has been proven to work and just needs a little tweaking doesn't make so much. Besides 'graphics' and AI we are not doing much different from the 80s at least. The software I write for mobile devices is in essence the same as the software I wrote for DOS/CPM/MSX. The crazy amount of time we spend on the frontend (animations, UI/UX etc) is very different from that time but the functionality is not very different. I actually wrote POS systems (for bars/restaurants) in the 80s (for a friend of the family), 90s, 2000s and this year and the logic / db stuff is the same for these. The only change is the GUI and even that not massively. Why didn't we write a POS in the 80s and just call that 'POS-barres', give it away for free and NEVER again write POS software for bars/restaurants? 'But they have different wishes!'. No they don't. I sold (as being the coder but also the (pre-)sales person); they don't have different wishes; every POS-barres is the same plus/minus some hardware and more (over time) data gathering. For me this falls under snake-oil; knowing my own ex company and my competitors; we sold basically lies ('our software is better' and luckily bar/restaurant owners have no clue what to say to that because if you go into it you would be hard pressed to even see any difference, maybe besides hardware support years back). This goes for many software systems. My first company wrote educational software sold to almost all schools in the Netherlands; this software is still sold, it runs on the same logic since the 80s (written in (Turbo) Pascal, directly imported into Delphi as unit in the 90s and on); the GUI and ofcourse the data in it was tweaked but the logic did not change. Sure we can now add advanced data analysis; but you don't have to add that INTO the software; you can do that in the cloud and make a screen to show the analysis results. That doesn't change the software and you could do implement the 'showing of the results' in the 80s. Sure we add AI but that can be added on mostly instead of rewriting from scratch.
- sklogic 10y ago
  Pretty much everything in the enterprise. It simply should not exist. All that CRUD stuff (that should have been automated long ago, it does not deserve all the boilerplate), everything Java, everything that is going on now in the Web. It is all amazingly overengineered. Doing things in an idiomatic Lisp way would have resulted in 1/1000th volume of a code doing 10x more. And, of course, in 95% of the developers being redundant.
deleted 10y ago
[deleted]
ZenoArrow 10y ago
Lisp has some good traits, but it isn't the 'ultimate' language. There are a number of issues with Lisp, for example I've heard debugging Lisp macros can be quite hard, I'd also say optional types is a weakness. Even Sussman, one of the creators of Scheme, classes Haskell as the best programming language we currently have, or in his words "the most advanced of the primitive languages.". http://limist.com/coding/talk-notes-we-really-dont-know-how-to-compute-gerald-sussman-2011.html http://limist.com/coding/talk-notes-we-really-dont-know-how-... That's not to say Lisp doesn't have merit, because it does, it's easy to pick up, very flexible, and in the right hands can lead to impressive results, but we've still got plenty of work to do to improve the state of the art.
- nickpsecurity 10y ago
  I agree. As sklogic showed, you can actually get the remaining attributes of LISP by building a Haskell or whatever on top of it. Doesn't have to be Common LISP or even a full LISP. Just the syntax, macros, eval, and basic compiler. One can do the rest in the other language as a DSL. And then another language as a DSL. And another. :)
- emidln 10y ago
  Debugging lisp macros is like debugging anything else. You have functions that take an input and produce an output. The input is data, the output is data, and there aren't likely side effects. Use the same tools to debug macros that you would use to debug other functions. We have debuggers, tracers, and the repl to help us debug macros, since macros are just normal lisp functions (that run at a different time than "normal" code).
- eggy 10y ago
  I wonder if Sussman has come across Shen [1]? It is a small Lisp based on Klambda, comprised of just 43 instructions, that has been ported to Common Lisp (SBCL), Haskell, Ruby and Emacs Lisp (just this month). It has also been ported to Python, Clojure, Javascript, Java, and the JVM which are not up to Shen 19 certification yet. Shen has pattern matching, an integrated fully functional Prolog, static type checking and even optional lazy evaluation. It has a very strong type system. Shen commercial has Griffin, an optimized compiler, SML (Shen Markup Language) to generate HTML, and concurrency. Popularity has not been my reason for selecting a language. I have been using J, an APL-derived, language for years, and I also like APL, K, and now Q! It is amusing to see developers rediscover APL concepts after 50 or more years! [1] http://shenlanguage.org/ http://shenlanguage.org/ [2] jsoftware.com
vortico 10y ago
I like your term "RDD". It seems like the type of development strategy where you write implementations of hash trees and database whenever you need them.
- wrong_variable 10y ago
  I didn't create the term RDD - that credit goes to http://radar.oreilly.com/2014/10/resume-driven-development.html http://radar.oreilly.com/2014/10/resume-driven-development.h... I do RDD since I want to watch the world burn and reap as much benefit from it before I drop dead.
incepted 10y ago
It goes both ways. Lisp has certain attributes that also make modern programmers go "Yeah, back then it sounded like a good idea". Being dynamically typed comes to mind.
- wtbob 10y ago
  Lisp is both dynamically and statically typed: (defun foo (x y) (declare (type (integer 1 12) x) (type character y)) (make-string x :initial-element y)) And the compiler will provide a compile-time error if someone tries to call (foo 1 2) but will accept (foo 1 #\a). Even cooler, it will provide a compile-time if the developer tries to call foo with a first argument which is not provably an integer from 1 to 12. In fact, you might even say that it's statically typed since values which have undeclared types are really of type T, but I don't think I'd go that far.
  - incepted 10y ago
    Sure, Lisp has many derivatives, some of which are statically typed. The most popular Lisp today, Clojure, is dynamically typed, though.
    - wtbob 10y ago
      Common Lisp not a Lisp derivative: it is Lisp. Someday, of course, there may be a successor language, but Clojure is not. Clojure is a Lisp-like language with — I'm told — many good and/or interesting idea. I don't know if it's actually the most popular Lisp-like language (I'd think Scheme would be), but it probably is more popular than Lisp. That's sad, but that's life.
    - TeMPOraL 10y ago
      Clojure is a kind of Javified Lisp; if you're looking for a canonical example, the GP provided an example of Common Lisp code, which gives you optional type declarations that are compile-time checked and are used by compilers to generate more optimized code.

biot 10y ago

What are some examples of problems that are being snake-oiled that were already solved half a century ago?

kuschku 10y ago
A lot of things currently done in the javascript world are just people discovering that the "just copy all code into a file" world of things doesn’t work – and so they reinvented modules, after the "kik" debacle, now reinvent namespaces, they reinvent dependency management, etc. Just look at the javascript world, they have enough examples.
- jonathankoren 10y ago
  This. JavaScript's engineering culture is a dumpster fire of 40 year old bad ideas that the rest of the software community abandoned 40 years ago.
  - neoeldex 10y ago
    It is a language in a constant changing environment. The web today has different requirements than 20 years ago. It's not right to criticize the reimplementation of things in different systems. That has to happen... Paradigms shift, so thus do implementations
    - jonathankoren 10y ago
      That doesn't explain the left-pad debacle, and the apologists defending that anti-pattern. That's a people problem, not a technology problem.
      - zaphar 10y ago
        Left pad was both. The ultra small single function library approach prevalent in npm is caused by fundamental limitations of javascript in the browser. The political issues that surfaced it all was a people problem.
        jonathankoren 10y ago
        While the impetus for a left-pad like function is due to a lack of a standard library, that's not what went wrong. Brushing the problem aside as merely a "political issue" shows that you don't understand what went wrong either. 1) The whole culture of bringing in a mass of external dependencies for single specialized functions is to be quite honest rather strange and problematic on it's own. Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time. 2) Bringing in an literally an unknown number of external dependencies is dependency hell. How many different left-pads and left-pad-likes do you have? Do you even know? 3) The justification of trivial functions as standalone dependencies is justified as a vetting process. Somehow by pulling in everything separate will improve code quality? No. Fixing bugs improves code quality. Honestly, someone in this very forum justified left-pad as a standalone because it helped "find edge cases." What's the edge case in left pad? There's literally only two edges. -1 and (padtosize - len(num)). On one end you get an undefined, and on the other, your string is wrong. Even if you walk off the entire string, you get another undefined. It's a lesson 1 Intro to Programming problem. 4) Having a bunch of minimum functions makes choosing the right one impossible, or maybe it doesn't matter at all, in which case what's the point. Seriously. I was going to make a remark about "Why not just implement printf?", when a quick google found THREE! printfs on npm (format, sprint, and qprintf.) And then of course there's left pad if all you want is "%03d". 5) The actually source of the left-pad debacle is autoupdating external dependencies from the Internet. This is a horrifically Bad Idea. It was a Bad Idea before the left-pad debacle, and it's a horrifically Bad Idea after the left-pad debacle. And I have no doubt that the javascript community did not learn this lesson. Instead it appears all that was learned was to be scared of trademark claims. Autoupdating dependencies is a Bad Idea because it's how you get bugs. Seriously, if the javascript community simply didn't do this, and instead followed the best practices software engineering practices since literally the dawn of external libraries, then the whole left-pad debacle would have been greatly mitigated. The whole security injection clusterfuck happened because the kid that runs NPM got scared because "code was breaking", of course it's not his code, it's just random code on the Internet, because the javascript community doesn't employ widely implemented best engineering practices. NPM as exploit delivery vector was always there, and it's still there if you don't do proper versioning and vetting of your external libraries. Passing the buck, isn't acceptable. Left-pad was to the greater software engineering community like the scene at the end of Lord of Flies, when the adult finally shows up, looks around at the chaos and says, "What are you guys doing?"
__s 10y ago
CRUD. My day job involves maintaining ASP webform sites which are a set of inputs to create compute contracts. Lots of copy pasted code I'm trying to consolidate. Lacks use of generics or ORM or form models
PeCaN 10y ago
Most of these are from the late 70s/early 80s, so not quite half a century. Debugging – look at Smalltalk if you don't believe me. Security – Intel i432 didn't sell well, but now we're sure wishing it had. The entire system was built on an object-capability model from the hardware up. The OS and userspace were fully written in Ada. Persistence – System/38 and AS/400 — everything has a persistent address. All pointers are 128-bit (yes... this was designed in the late 70s). Everything is an object and the OS has a built-in database. You can persist anything effortlessly. String processing – Regular expressions are useful; SNOBOL is more readable, more powerful, more efficient, and existed in 1962. Awk is a joke. Declarative programming – I feel like Greenspun's 10th Rule applies at least as much to Prolog as it does to Lisp. The sheer number of cases where embedding a little unification engine dramatically simplifies code is pretty baffling. GUIs – we've almost caught up to the ease of use of the Dynamic Windows system on Symbolics Lisp machines. Concurrency – it amuses me that Go gets so much attention lately when it's just a re-skin of Occam from 1983. Probably more. I feel like i432 and AS/400 in particular were very, very ahead of their time.
- viraptor 10y ago
  Do you really think a very high level processor was the way to go? It seems like we're just going lower and lower in the stack in the more advanced applications. I mean, on i432 (from what I learned about it) you couldn't even free memory - you were stuck in it's specific instructions, GC, and other elements. It could be an interesting version of a secure execution enclave (like Intel tries to create today), but I'm not sure it would be useful or performant in general processing.
  - sklogic 10y ago
    Tagged memory was definitely a way to go. Would have eliminated most of the security issues we had so far. Luckily, it's slowly making a comeback, see the RISC-V efforts for example.
    - pjmlp 10y ago
      And Intel's MPX. We already had all of that in the early 60's with Lisp and Algol dialects based OSes. Apparently we need to have daily memory corruption CVE's as industry wake-up call.
tluyben2 10y ago
Not really 'problems' but some examples of things which did not had to be written over and over; we still do so because it is a) hard to reuse software b) we have no source from others c) snake-oil; we want to make money and just giving them something that has been proven to work and just needs a little tweaking doesn't make so much. Besides 'graphics' and AI we are not doing much different from the 80s at least. The software I write for mobile devices is in essence the same as the software I wrote for DOS/CPM/MSX. The crazy amount of time we spend on the frontend (animations, UI/UX etc) is very different from that time but the functionality is not very different. I actually wrote POS systems (for bars/restaurants) in the 80s (for a friend of the family), 90s, 2000s and this year and the logic / db stuff is the same for these. The only change is the GUI and even that not massively. Why didn't we write a POS in the 80s and just call that 'POS-barres', give it away for free and NEVER again write POS software for bars/restaurants? 'But they have different wishes!'. No they don't. I sold (as being the coder but also the (pre-)sales person); they don't have different wishes; every POS-barres is the same plus/minus some hardware and more (over time) data gathering. For me this falls under snake-oil; knowing my own ex company and my competitors; we sold basically lies ('our software is better' and luckily bar/restaurant owners have no clue what to say to that because if you go into it you would be hard pressed to even see any difference, maybe besides hardware support years back). This goes for many software systems. My first company wrote educational software sold to almost all schools in the Netherlands; this software is still sold, it runs on the same logic since the 80s (written in (Turbo) Pascal, directly imported into Delphi as unit in the 90s and on); the GUI and ofcourse the data in it was tweaked but the logic did not change. Sure we can now add advanced data analysis; but you don't have to add that INTO the software; you can do that in the cloud and make a screen to show the analysis results. That doesn't change the software and you could do implement the 'showing of the results' in the 80s. Sure we add AI but that can be added on mostly instead of rewriting from scratch.
sklogic 10y ago
Pretty much everything in the enterprise. It simply should not exist. All that CRUD stuff (that should have been automated long ago, it does not deserve all the boilerplate), everything Java, everything that is going on now in the Web. It is all amazingly overengineered. Doing things in an idiomatic Lisp way would have resulted in 1/1000th volume of a code doing 10x more. And, of course, in 95% of the developers being redundant.

deleted 10y ago

[deleted]

ZenoArrow 10y ago

Lisp has some good traits, but it isn't the 'ultimate' language. There are a number of issues with Lisp, for example I've heard debugging Lisp macros can be quite hard, I'd also say optional types is a weakness. Even Sussman, one of the creators of Scheme, classes Haskell as the best programming language we currently have, or in his words "the most advanced of the primitive languages.". http://limist.com/coding/talk-notes-we-really-dont-know-how-to-compute-gerald-sussman-2011.html http://limist.com/coding/talk-notes-we-really-dont-know-how-... That's not to say Lisp doesn't have merit, because it does, it's easy to pick up, very flexible, and in the right hands can lead to impressive results, but we've still got plenty of work to do to improve the state of the art.

nickpsecurity 10y ago
I agree. As sklogic showed, you can actually get the remaining attributes of LISP by building a Haskell or whatever on top of it. Doesn't have to be Common LISP or even a full LISP. Just the syntax, macros, eval, and basic compiler. One can do the rest in the other language as a DSL. And then another language as a DSL. And another. :)
emidln 10y ago
Debugging lisp macros is like debugging anything else. You have functions that take an input and produce an output. The input is data, the output is data, and there aren't likely side effects. Use the same tools to debug macros that you would use to debug other functions. We have debuggers, tracers, and the repl to help us debug macros, since macros are just normal lisp functions (that run at a different time than "normal" code).
eggy 10y ago
I wonder if Sussman has come across Shen [1]? It is a small Lisp based on Klambda, comprised of just 43 instructions, that has been ported to Common Lisp (SBCL), Haskell, Ruby and Emacs Lisp (just this month). It has also been ported to Python, Clojure, Javascript, Java, and the JVM which are not up to Shen 19 certification yet. Shen has pattern matching, an integrated fully functional Prolog, static type checking and even optional lazy evaluation. It has a very strong type system. Shen commercial has Griffin, an optimized compiler, SML (Shen Markup Language) to generate HTML, and concurrency. Popularity has not been my reason for selecting a language. I have been using J, an APL-derived, language for years, and I also like APL, K, and now Q! It is amusing to see developers rediscover APL concepts after 50 or more years! [1] http://shenlanguage.org/ http://shenlanguage.org/ [2] jsoftware.com

vortico 10y ago

I like your term "RDD". It seems like the type of development strategy where you write implementations of hash trees and database whenever you need them.

wrong_variable 10y ago
I didn't create the term RDD - that credit goes to http://radar.oreilly.com/2014/10/resume-driven-development.html http://radar.oreilly.com/2014/10/resume-driven-development.h... I do RDD since I want to watch the world burn and reap as much benefit from it before I drop dead.

incepted 10y ago

It goes both ways. Lisp has certain attributes that also make modern programmers go "Yeah, back then it sounded like a good idea". Being dynamically typed comes to mind.

wtbob 10y ago
Lisp is both dynamically and statically typed: (defun foo (x y) (declare (type (integer 1 12) x) (type character y)) (make-string x :initial-element y)) And the compiler will provide a compile-time error if someone tries to call (foo 1 2) but will accept (foo 1 #\a). Even cooler, it will provide a compile-time if the developer tries to call foo with a first argument which is not provably an integer from 1 to 12. In fact, you might even say that it's statically typed since values which have undeclared types are really of type T, but I don't think I'd go that far.
- incepted 10y ago
  Sure, Lisp has many derivatives, some of which are statically typed. The most popular Lisp today, Clojure, is dynamically typed, though.
  - wtbob 10y ago
    Common Lisp not a Lisp derivative: it is Lisp. Someday, of course, there may be a successor language, but Clojure is not. Clojure is a Lisp-like language with — I'm told — many good and/or interesting idea. I don't know if it's actually the most popular Lisp-like language (I'd think Scheme would be), but it probably is more popular than Lisp. That's sad, but that's life.
  - TeMPOraL 10y ago
    Clojure is a kind of Javified Lisp; if you're looking for a canonical example, the GP provided an example of Common Lisp code, which gives you optional type declarations that are compile-time checked and are used by compilers to generate more optimized code.