Live data from Hacker News

On Getting Older in Tech

corgibytes.com

351–360 of 440 posts

Re: On Getting Older in Tech

#351
post #108
post #96

Earlier quoted context omitted.

> And that makes me grumpy sometimes. If you will excuse a moment of cheekiness... Could be that you have cause and effect backwards here: because you are grumpy you are dismissing 99% of other language developers' work as rubbish. Could be that it's less than 99% and you are overlooking some great ideas.

That's not cheeky, it's a perfectly fair question. Yes, that is certainly possible. And there have been a few cool new ideas that have come along that are not easily subsumed by CL, like Haskell's type system. It's easy to implement Hindley-Milner, but actually using that information to inform the compiler, plus adding laziness as a core language feature, is much harder. But I think the jury is still very much out on…

Some functional languages make certain behaviors implicit, such as partial evaluation and laziness. However, these work better if they are explicit. They work better because one of the two is severely confusing when implicit and the other potentially performs badly.

  C:\Users\kaz>txr
  This is the TXR Lisp interactive listener of TXR 162.
  Use the :quit command or type Ctrl-D on empty line to exit.
  1> (defstruct integers ()
       val next
       (:postinit (me)
         (set me.next (lnew integers val (succ me.val))))
       (:method print (me stream pretty-p)
         (format stream "#" me.val)))
  #
  2> (lnew integers val 0)
  #
  3> *2.next
  #
  4> *2.next.next
  #
  5> *2.next.next.next
  #
Why would I want implicit laziness everywhere? The best of all worlds is to have expressions reduced to their values eagerly before a function call takes place.

When I don't want an expression evaluated in (what looks like) a function call, I can, firstly, make that a macro.

If I really want lazy semantics, I can have a decent vocabulary of lazy constructs that fit into the eager language. For instance for making objects lazily I have lnew, distinct from new.

Implicit laziness everywhere is academically stupid. You're drowning the execution of the code in an ocean of thunks and closures.

The pragmatic approach is best of making a compromise between making everything explicit and visible, yet keeping it syntactically tidy and convenient.

Re: On Getting Older in Tech

#352

Earlier quoted context omitted.

Torvalds, 46, can point to Linux and say "I made that, over half a lifetime ago". Stallman, 63, can point to GNU Emacs or GCC and say "I made that in the 1980's". Not necessarily the most recent version of it, but that hardly matters. Gerald Sussman and Guy Steele can point to Scheme and say, "we made that". John MacCarthy was able to point to Lisp and say "I made that", right to the day he died and we can continue t…

That's like saying da Vinci is representative of artists or Prince is representative of musicians. The average person who doesn't achieve software legend status will see their creations vanish as the previous commenter described. I've worked in this industry for a long time as well, but I'm not someone you've heard of. I too have built some very cool things that I'm proud of, a number of which no longer exist. Meanwh…

If you make something when you're 20, and just keep maintaining it until you die at the TTY prompt at 85, then all your life you were able to point to it and say "I made that (and am still making it better)". This is the case even if that work isn't well known. Perhaps nobody else will point to it for you after you're gone, but while you are here, you can say that.

Things you hacked up in the past are gone because they solved a narrowly defined problem which no longer exists, and even before that happened, you already abandoned those programs.

That this happens is almost inevitable, as part of making a living. All those programming DaVinci's who are known for something also worked on lots of things that are now dust.

Re: On Getting Older in Tech

#353
post #344

The problem is not age, it's being rusty. Far too many of the over 40 crowd I've interviewed appear to have stagnated. EDIT - to whoever downvoted me, grow a pair and reply instead of downvoting because you don't want to hear reality. I'm a gray beard myself. I've done hundreds of interviews in the past 5 years and know what I'm talking about in this respect...there are far too many programmers who get comfortable in…

The guidelines ask us not to complain about downvotes in the first place, but we certainly can't go off like this. https://news.ycombinator.com/newsguidelines.html

Perhaps you're being too sensitive. The OP is complaining that older engineers have trouble getting a job. I'm suggesting that rusty engineers have trouble, and age may not be a factor. That somebody didn't want to hear it and downvoted me as a result wasn't particularly constructive.

Re: On Getting Older in Tech

#354

Earlier quoted context omitted.

I heard this so many times before about just another language... learning language itself? yes, can be done damn fast, plus everybody had some java-like language in their studies. Knowing this means almost nothing, we're talking about very junior-level resource. You know gazillions of frameworks to achieve everything these days, their integration tricks, various app servers, CI toolsets and so on and on? I mean, if y…

I'm sorry. No actual senior person who is senior at java or c# takes months of babysitting to switch to the other. The beauty of a senior person over someone who is junior and knows only js, is that the senior person should have used many languages over their careers. Picking up a new language and/or framework is what senior people should be doing best. Most of the factors that go into a proper maintainable solution…

I'm not the person you're replying to, but can you really argue that someone senior who doesn't know a language and its associated frameworks is equivalent to someone who does know those things or deserves to be paid the same?

Sure, it's true that many things about good design are language agnostic. On the other hand, frameworks and languages can actually limit or enable what you can do, and that lack of familiarity with them has the potential to lead to mistakes.

Re: On Getting Older in Tech

#355

Earlier quoted context omitted.

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

You are writing this comment in the lisp-based software. Yeah, I know, Hacker news is a simple software and could have been written in anything else, but, somehow, the author, who I've heard is very smart, thought that Lisp is the best pick.

And his secret to winning big was "write lisp software, have it bought out by another company who will rewrite it in a different language to make it popular and useful".

Really, if PG's "LISP, how to win big" was as compelling and important as he tried to state in that essay, every ycombinator company would be using LISP for their secret advantage over other companies.

Applicants would choose LISP because it's "better", LISP-based applications would be preferred because the applicants have an advantage, existing companies would be encouraged to LISP because it would help them do more for less employee numbers and YC would become a LISPy community of alumni.

I have no proof that this is not happening right now, but would you bet on it happening right now in secret?

Re: On Getting Older in Tech

#356
post #103

Earlier quoted context omitted.

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

Sure, in practice people's beliefs about languages can become self-fulfilling prophecies. And the thing about self-fulfilling prophecies is that they are actually true. For example, Javascript is tremendously useful even thought it is a horrible language from a technical point of view, it's just that the sheer weight of people using it because everyone else is using it results in enough infrastructure that you can ge…

And when JavaScript was becoming a thing, where was the better alternative written in LISP and the community of people who like better software supporting it?

Nowhere, that's where. Like in approximately all problem domains, whatever perceived benefits LISP has, doesn't seem to make it all that desirable.

Re: On Getting Older in Tech

#357
post #159

Earlier quoted context omitted.

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

>Nobody uses it, but it's the best choice, both can't be true Sure it can. It is possible for both to be true, as long as developers don't pick languages rationally, which they probably don't. There are a few biases at play. One is that people are only exposed to a subset of the languages that exist, which are those that are either used in industry, or are making the rounds in news. Another bias is that we like to pi…

I also doubt it. But LISP dates back to 1958.

JavaScript is from 1995.

"I chose the language which exists" doesn't apply to the people in 1994 who could have had /thirty-five years/ of LISP experience (potentially) and yet still chose to write another language, in another language. And when Brendan Eich was in college around 1981, the tutors there could have had /twenty years/ of LISP experience, but weren't there to convince him that it was amazing.

Same with literally any language dating post-LISP, and I note that that covers most languages which are popular today.

"Programmers don't pick rationally" is fine on the small scale, but accross the entire industry, even among people who do love exploring programming languages, even among young entrepreneurial risk takers, even among companies in tough markets angling for any and every edge they can get over their competitors, in decade after decade, over problem domain after problem domain after problem domain, there is this empty howling wasteland of happy and productive people using not-LISP, writing world-conquering systems that do just-fine-thanks and the claimed benefits of LISP just don't seem to be making any noticable dent in anything.

Therefore, they are over-hyped.

Re: On Getting Older in Tech

#358
post #297

Earlier quoted context omitted.

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

Please. You pick a lowest-common-denominator language like Java or Golang so that you have a large pool of cheap, semi-sentient code monkeys to hire from. If you choose LISP, you're actually going to have to expend a little bit of effort on identifying, recruiting, and retaining actually competent people. That's a problem when you're looking to put butts-in-seats (as is the case in my industry: defense).

That just pushes the problem back a couple of decades. Common-LISP is from 1984, GoLang is from 2007.

In twenty years, Common-LISP with all the advantage it supposedly has couldn't make anything that a 'code monkey' could use? Why not? Is it awful at writing tools?

Or is it that the alledged advantages of Common-LISP don't really make any difference in reality because they are over-hyped or even non-existent?

Note that I'm not saying "why did they pick one language over another", I'm saying "Common LISP can be the best tool for the job - yet they waited twenty years to use a 'worse' tool to implement a 'worse' tool". That doesn't make sense.

Re: On Getting Older in Tech

#359
post #55

One of the things that has made me old (52) and crotchety is that I learned Lisp very early in my career. That gave me the ability to see that 99% of "new" technologies were really just poor re-inventions of (parts of) Lisp. Even today, Common Lisp -- despite (or, as some would argue, because of) the fact that it hasn't been officially updated in decades is still not only a viable language but one of the best choices…

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

> Nobody uses it

This application is written in 7+ million lines of Common Lisp

https://www.ptc.com/cad/elements-direct/modeling

https://www.youtube.com/watch?v=mJGytRaNvec

The video shows how Eterna uses 'PTC Creo Elements/Direct' to develop their watches. There are many other clients of that in various domains.

Also:

https://www.youtube.com/watch?v=4rD0zmA-Trc

Re: On Getting Older in Tech

#360
post #85

Earlier quoted context omitted.

Even today, Common Lisp is still one of the best choices for many applications. Then why don't people build amazing and popular things with it? I don't mean one or two people build one or two things, but lots of people building lots of things. Nobody uses it, but it's the best choice, can't both be true. And 'nobody uses it' is approximately true. It's not a mainstream JVM language or CLR language, it's not an AWS or…

Then why don't people build amazing and popular things with it? The reason is because "best" can have more than one meaning. Languages are usually only "best" at one thing, not for all things. In the case of many languages that people consider to be "best", they've been optimised for the development process (making it nice to write code in) rather than speed (C) or security (Ada) or a specific niche (R) or maintainab…

I would go with that, in the sense that "here's a box of parts" is the most customisable way to solve a problem - yet not the best way for most people.

Except, even people doing exploratory stuff apparently aren't using Common-LISP.

Let me point to Slava from RethinkDB, who wrote blogs about how amazing LISP is and then went to found a new-software startup written in C++. Peter Norvig, AI researcher, who moved from LISP to Python.

And even your mention of Ruby - "Common LISP is the best langauge", then why is Ruby even needed? Why aren't those people happily using Common LISP? Simply because it wasn't actually any better, and was in fact worse than Ruby in whatever metrics.

Post reply on HN