6 ms·

Late forties developer here. > Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. There's my problem right aw

Late forties developer here. > Every time I feel like I'm "out of touch" with the hip new thing, I take a weekend to look into it. There's my problem right away. I can't just "take a weekend" to learn some new shiny thing. I have a partner and children who I want to be with at the weekend. And I'd rather go climbing or hiking or even just go out on my bike, than learn another damn api. Twenty years ago I had evenings and weekends to burn. Now I don't.

toxik 10y ago
I'm 26, and modulo the kids, this is how I feel as well. I've been programming professionally for almost ten years, and I feel less and less pressure to keep up with the latest packages on NPM or whatever the flavor of the month is. It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake.
- fao_ 10y ago
  NewLisp is over 25 years old.
- progman 10y ago
  > why should we suddenly start writing Lisp? The language is older than C, for god's sake. If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing? All those nice "new" features which Python and C++ are praised for (lambdas, closures, list comprehensions) have been available for almost 50 years. Lisp was way ahead of its time. It just lacked the hardware power which we have today. It is still ahead of our time. Consider Lisp macros, Genera and MCCLIM. MCCLIM is an interactive GUI for shells which has been neglected for decades. It is being revived right now to make it available for modern Lisp distributions. Modern Lisp just lacks one thing to be the real deal: a native Lisp Machine. https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/
  - jerf 10y ago
    "If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing?" Because if it hasn't "succeeded", for suitable definitions of "succeeded" in 50 years, as an old fart approaching 40 myself my assumption is that there is a good reason. I was much more willing to believe the "everybody else is just stupid and can't see the obvious brilliance" reason when I was younger, but as I've learned more, I've learned just how many factors go into a language being successful. Lisp may have all the features, but there are also good reasons why it has never really quite taken off. That said, it is also true that using languages that bodge Lisp-like features on to the side after several decades of usage is generally inferior to languages that start with them. It's one of the reasons I'm still a big proponent of people making new languages even though we've got a lot of good ones. (I just want them to be new languages somehow; a lot of people just reskin an existing language with a slightly different syntax and then wonder why nobody uses it.) But they've all been listed before, and I don't expect me listing them here will change anything, so I'll skip it here. (I did a quick check on Google Trends; Clojure seems to not be growing. It's not shrinking, but it's not growing. That was Lisp's best chance for growth I've seen in a long time, and that window has probably now closed.)
    - progman 10y ago
      The reason why Lisp is not mainstream is its power. It makes writing DSLs extremely easy so that everyone can write his own DSL to solve a certain problem. Such style of writing however makes Lisp code unsuitable for group working, and hence unmaintainable. It explains (imho) why there are so many unmaintained Lisp projects. Clojure has a different problem. It is based on the JVM infrastructure which was (imho) an unfortunate decision. Access to Java features is nice but dealing with Java stack traces is not fun. Also the usual startup time of clojure apps in the range of seconds is not acceptable (Tcl/Tk apps start in a fraction of a second). AFAIK clojure is also not suitable for mobile app development. The clojure developers should have used their own VM, or they should have provided a Clojure/Lisp compiler for native compilation. LuaJit has demonstrated how incredibly fast a suitable VM can be.
      - 10y ago
- chriswarbo 10y ago
  > It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake. I wouldn't say Lisp "didn't stick"; it's been in continuous use for half a century. Writing Lisp code would be anything but "sudden". Of course we can say the same thing about COBOL, but that seems mostly due to the inertia of legacy applications; its target demographic of business applications now favours languages like Java. On the other hand, new projects are being written in Lisps, and it's still spawning new languages (e.g. Common Lisp, Clojure, Kernel, all the Schemes and their descendents, etc.). This seems to indicate that people want to use/extend Lisp, rather than having to use it (although there are certainly legacy Lisp applications out there, which may or may not be horrendous to maintain). Also, as Alan Kay points out, Lisps frequently "eat their children": someone invents a "better language", then someone else figures out a way to do the same thing as a library in an existing Lisp. This means that very old dialects/implementations may be perfectly capable of using paradigms/fads/etc. which were only invented/popularised much later, e.g CLOS for OOP or call/cc, shift/reset, etc. for coroutines/async/promises/etc. In contrast, those languages which truly "didn't stick" are seldom heard of, outside the "inspired by" sections on Wikipedia. Many of are uninteresting, such as machine- or company-specific dialects, which died along with their hardware/sponsor. Others can be very informative, especially regarding "flavours of the month" and "paradigm shifts": - Simula (arguably the origin of OOP as found in C++, Java, C#, etc.) - ALGOL (the archetype of lexically-scoped procedural languages, like Pascal, C, Go, etc.). Actually, I still see "idealised Algol" discussed in cutting-edge programming language research, so maybe it still has some life! - SNOBOL, which enjoyed great success in the world of string manipulation, and now seems to be completely replaced by awk/sed/perl/tcl/etc. - MUMPS, which integrated a key/value database into the language. Still used, but seems to be for legacy reasons like COBOL (e.g. see http://thedailywtf.com/articles/A_Case_of_the_MUMPS http://thedailywtf.com/articles/A_Case_of_the_MUMPS ) - Refal, which relies on pattern-matching for evaluation (now widespread in the MLs (Standard ML, OCaml, F#, Coq, etc.) and Haskell-likes (Haskell, Clean, Miranda, Curry, Agda, Idris, etc.). Also notable for using supercompilation. - ABC, the prototypical 'scripting language', and a direct influence on Python. - FP, which emphasised higher-order programming. - Joy, a pure functional language based on stacks and composition, rather than lambda calculus. - REXX, widely used as a "glue" language; I think AppleScript has comparable use-cases these days (I don't know, I've never used an Apple OS). Seems to be supplanted by shells and embedded scripting languages (e.g. Python, Lua, JS) - Self, famous for prototypical inheritance and the origin of the "morphic" GUI. - Dylan, effectively a Lisp without the s-expressions. Created by Apple, but quickly abandoned. - Prolog, a logic language based on unification. Still has some users, but didn't take over the world as some thought it would (e.g. the whole "fifth generation" hype in the 80s).
- greenshackle2 10y ago
  I'm 26 and I'm just starting my career. You're making me feel old.
  - y4mi 10y ago
    i'm 28 and am still useless. don'T feel bad.
3chelon 10y ago
Another (very) late forties dev here too. Your use of the word "burn" concerns me. I'd prefer the word "invest". As I've said before on this subject, if you're careful what shiny new thing you bother to learn, and restrict yourself to doing it every couple of years rather than every weekend, I find the family and kids will never notice. And anyway, at our age time flies so damn fast the kids'll be grown up by next weekend anyway :)
- andyjohnson0 10y ago
  Good point. Appreciate your concern, but I wasn't being clear. By time to "burn" I was referring to all the time I had in my twenties: when spending an evening or a day or a weekend doing nothing in particular didn't seem like much of a waste. Whereas now, "me-time" comes in much smaller units (maybe an hour after the kids are in bed and before I get tired). And I'm very careful to invest it: I recently spent eight months studying UX on Coursera, and am getting back into electronics and Arduino after a break, for example. I just don't have big blocks of time any more. Certainly not whole weekends.
- dwc 10y ago
  Early fifties here. > Your use of the word "burn" concerns me. I'd prefer the word "invest". I agree, but... sometimes it really is "burn". I don't keep up with front-end tech these days. If/when I need to work with it I'll learn it, and not before. If I spent time getting up to a real working knowledge now, there's every chance that in, say, 4 years when I needed to work in that space that I'd have to start learning from scratch again rather than brush up. I do spend time learning new (to me) things, but I'm very selective. I devote most of my time to learning things that will give me alternate ways of doing things, rather than learning every nut and bolt of the latest framework.
delinka 10y ago
The frequency with which "hot new things" appear isn't every week. I'd venture a guess and say one weekend every two months. I don't know where you live, but here the weather isn't perfect for 52 weekends of the year. Some weekends it's not even worth sitting in front of the computer - total laziness with the family is ideal.
city41 10y ago
I'm 39. There's no denying tech requires you to constantly keep up. But in my opinion, it's not as bad as most make it out to be. For the most part I read blogs while lying in bed at night (about 15 minutes or so), and I always have a side project going that I get to here and there. I still maintain a healthy life balance and get to enjoy things outside of tech just fine. To be fair, I don't have kids. I'm sure that's a huge factor.
Iv 10y ago
Soon in my forties. When I need to take a few days to look into something, I do it as part of my work. That's part of the maintenance of having a senior and experienced programmer. Some times, my boss asks me about a new fancy tech. "I'll look into it" means I'll take a few hours of my time to give a good appraisal of it.

toxik 10y ago

I'm 26, and modulo the kids, this is how I feel as well. I've been programming professionally for almost ten years, and I feel less and less pressure to keep up with the latest packages on NPM or whatever the flavor of the month is. It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake.

fao_ 10y ago
NewLisp is over 25 years old.
progman 10y ago
> why should we suddenly start writing Lisp? The language is older than C, for god's sake. If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing? All those nice "new" features which Python and C++ are praised for (lambdas, closures, list comprehensions) have been available for almost 50 years. Lisp was way ahead of its time. It just lacked the hardware power which we have today. It is still ahead of our time. Consider Lisp macros, Genera and MCCLIM. MCCLIM is an interactive GUI for shells which has been neglected for decades. It is being revived right now to make it available for modern Lisp distributions. Modern Lisp just lacks one thing to be the real deal: a native Lisp Machine. https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/
- jerf 10y ago
  "If so many "modern" languages still copy features from Lisp (hello C++) then why not use the real thing?" Because if it hasn't "succeeded", for suitable definitions of "succeeded" in 50 years, as an old fart approaching 40 myself my assumption is that there is a good reason. I was much more willing to believe the "everybody else is just stupid and can't see the obvious brilliance" reason when I was younger, but as I've learned more, I've learned just how many factors go into a language being successful. Lisp may have all the features, but there are also good reasons why it has never really quite taken off. That said, it is also true that using languages that bodge Lisp-like features on to the side after several decades of usage is generally inferior to languages that start with them. It's one of the reasons I'm still a big proponent of people making new languages even though we've got a lot of good ones. (I just want them to be new languages somehow; a lot of people just reskin an existing language with a slightly different syntax and then wonder why nobody uses it.) But they've all been listed before, and I don't expect me listing them here will change anything, so I'll skip it here. (I did a quick check on Google Trends; Clojure seems to not be growing. It's not shrinking, but it's not growing. That was Lisp's best chance for growth I've seen in a long time, and that window has probably now closed.)
  - progman 10y ago
    The reason why Lisp is not mainstream is its power. It makes writing DSLs extremely easy so that everyone can write his own DSL to solve a certain problem. Such style of writing however makes Lisp code unsuitable for group working, and hence unmaintainable. It explains (imho) why there are so many unmaintained Lisp projects. Clojure has a different problem. It is based on the JVM infrastructure which was (imho) an unfortunate decision. Access to Java features is nice but dealing with Java stack traces is not fun. Also the usual startup time of clojure apps in the range of seconds is not acceptable (Tcl/Tk apps start in a fraction of a second). AFAIK clojure is also not suitable for mobile app development. The clojure developers should have used their own VM, or they should have provided a Clojure/Lisp compiler for native compilation. LuaJit has demonstrated how incredibly fast a suitable VM can be.
    - 10y ago
chriswarbo 10y ago
> It's much more interesting to know what has been tried before, and why that didn't stick. Like this newLISP thing, why should we suddenly start writing Lisp? The language is older than C, for god's sake. I wouldn't say Lisp "didn't stick"; it's been in continuous use for half a century. Writing Lisp code would be anything but "sudden". Of course we can say the same thing about COBOL, but that seems mostly due to the inertia of legacy applications; its target demographic of business applications now favours languages like Java. On the other hand, new projects are being written in Lisps, and it's still spawning new languages (e.g. Common Lisp, Clojure, Kernel, all the Schemes and their descendents, etc.). This seems to indicate that people want to use/extend Lisp, rather than having to use it (although there are certainly legacy Lisp applications out there, which may or may not be horrendous to maintain). Also, as Alan Kay points out, Lisps frequently "eat their children": someone invents a "better language", then someone else figures out a way to do the same thing as a library in an existing Lisp. This means that very old dialects/implementations may be perfectly capable of using paradigms/fads/etc. which were only invented/popularised much later, e.g CLOS for OOP or call/cc, shift/reset, etc. for coroutines/async/promises/etc. In contrast, those languages which truly "didn't stick" are seldom heard of, outside the "inspired by" sections on Wikipedia. Many of are uninteresting, such as machine- or company-specific dialects, which died along with their hardware/sponsor. Others can be very informative, especially regarding "flavours of the month" and "paradigm shifts": - Simula (arguably the origin of OOP as found in C++, Java, C#, etc.) - ALGOL (the archetype of lexically-scoped procedural languages, like Pascal, C, Go, etc.). Actually, I still see "idealised Algol" discussed in cutting-edge programming language research, so maybe it still has some life! - SNOBOL, which enjoyed great success in the world of string manipulation, and now seems to be completely replaced by awk/sed/perl/tcl/etc. - MUMPS, which integrated a key/value database into the language. Still used, but seems to be for legacy reasons like COBOL (e.g. see http://thedailywtf.com/articles/A_Case_of_the_MUMPS http://thedailywtf.com/articles/A_Case_of_the_MUMPS ) - Refal, which relies on pattern-matching for evaluation (now widespread in the MLs (Standard ML, OCaml, F#, Coq, etc.) and Haskell-likes (Haskell, Clean, Miranda, Curry, Agda, Idris, etc.). Also notable for using supercompilation. - ABC, the prototypical 'scripting language', and a direct influence on Python. - FP, which emphasised higher-order programming. - Joy, a pure functional language based on stacks and composition, rather than lambda calculus. - REXX, widely used as a "glue" language; I think AppleScript has comparable use-cases these days (I don't know, I've never used an Apple OS). Seems to be supplanted by shells and embedded scripting languages (e.g. Python, Lua, JS) - Self, famous for prototypical inheritance and the origin of the "morphic" GUI. - Dylan, effectively a Lisp without the s-expressions. Created by Apple, but quickly abandoned. - Prolog, a logic language based on unification. Still has some users, but didn't take over the world as some thought it would (e.g. the whole "fifth generation" hype in the 80s).
greenshackle2 10y ago
I'm 26 and I'm just starting my career. You're making me feel old.
- y4mi 10y ago
  i'm 28 and am still useless. don'T feel bad.

3chelon 10y ago

Another (very) late forties dev here too. Your use of the word "burn" concerns me. I'd prefer the word "invest". As I've said before on this subject, if you're careful what shiny new thing you bother to learn, and restrict yourself to doing it every couple of years rather than every weekend, I find the family and kids will never notice. And anyway, at our age time flies so damn fast the kids'll be grown up by next weekend anyway :)

andyjohnson0 10y ago
Good point. Appreciate your concern, but I wasn't being clear. By time to "burn" I was referring to all the time I had in my twenties: when spending an evening or a day or a weekend doing nothing in particular didn't seem like much of a waste. Whereas now, "me-time" comes in much smaller units (maybe an hour after the kids are in bed and before I get tired). And I'm very careful to invest it: I recently spent eight months studying UX on Coursera, and am getting back into electronics and Arduino after a break, for example. I just don't have big blocks of time any more. Certainly not whole weekends.
dwc 10y ago
Early fifties here. > Your use of the word "burn" concerns me. I'd prefer the word "invest". I agree, but... sometimes it really is "burn". I don't keep up with front-end tech these days. If/when I need to work with it I'll learn it, and not before. If I spent time getting up to a real working knowledge now, there's every chance that in, say, 4 years when I needed to work in that space that I'd have to start learning from scratch again rather than brush up. I do spend time learning new (to me) things, but I'm very selective. I devote most of my time to learning things that will give me alternate ways of doing things, rather than learning every nut and bolt of the latest framework.

delinka 10y ago

The frequency with which "hot new things" appear isn't every week. I'd venture a guess and say one weekend every two months. I don't know where you live, but here the weather isn't perfect for 52 weekends of the year. Some weekends it's not even worth sitting in front of the computer - total laziness with the family is ideal.

city41 10y ago

I'm 39. There's no denying tech requires you to constantly keep up. But in my opinion, it's not as bad as most make it out to be. For the most part I read blogs while lying in bed at night (about 15 minutes or so), and I always have a side project going that I get to here and there. I still maintain a healthy life balance and get to enjoy things outside of tech just fine. To be fair, I don't have kids. I'm sure that's a huge factor.

Iv 10y ago

Soon in my forties. When I need to take a few days to look into something, I do it as part of my work. That's part of the maintenance of having a senior and experienced programmer. Some times, my boss asks me about a new fancy tech. "I'll look into it" means I'll take a few hours of my time to give a good appraisal of it.