On Getting Older in Tech • Hacker News Board

Re: On Getting Older in Tech

#381

Post by AnimalMuppet » Sat, Dec 10, 2016, 1:27 AM UTC

reikonomusha wrote: post #86

jodrellblank wrote: post #81

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…

A few notes: * Google actively develops one of the Lisp compilers. Google Flights powers Orbitz, Kayak, etc. That's Lisp. * There are several Lisp compilers in active open source development. * There's a graph database written in Lisp called AllegroCache. It's good enough to support a business (Franz) for more than a decade. * Another company (LispWorks) also exists and has a large portfolio of clients. * Lisp has be…

> But where are real OS's with GUIs in other languages?

There's this thing called Windows you may have heard of...

And, out of curiosity, what OS are you referring to?

> Just because there's not this huge buzz around Lisp doesn't mean no one is using it.

jodrellblank's claim was not that absolutely nobody is using it. The claim was, compared to how wonderful Lisp advocates claim the language is, relatively nobody is using it. If you compare the amount of software written in Lisp to the total amount of software written, and compare that to how wonderful Lisp is claimed to be, jodrellblank has a real point. And citing a handful (or several handfuls) of counter-examples does not refute the point at all.

Re: On Getting Older in Tech

#382

Post by mianos » Sat, Dec 10, 2016, 1:34 AM UTC

rifung wrote: post #354

matwood wrote: post #309

Earlier quoted context omitted.

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…

If the more senior program is of the same calibre and lacks skill in a language, then 100% yes. The idea of discounting proper experience is a clear example of the Dunning Kruger effect.

Re: On Getting Older in Tech

#383

Post by AnimalMuppet » Sat, Dec 10, 2016, 1:36 AM UTC

lispm wrote: post #367

jodrellblank wrote: post #361

Earlier quoted context omitted.

It might be that it really is a big secret, and people are quietly using it and gaining advantages from it. If that were the case, I would still expect to see lots of gushing blogs of leaks from inside hush-hush companies and people desperate to learn LISP posting "how do I replace strings in files in Common LISP" on programming forums, and "I learned LISP and doubled my salary" on Twitter. Yet what you really see is…

Lisp is old and it's unlikely that you see hype anytime soon. But you can see that Lisp derived languages like Clojure can generate minor hypes. Other new languages may even contain substantial pieces of Lisp influence. Examples would be Julia or R. Generally the industry has problems reusing old/existing technology. See for example the Javascript domain, where new frameworks for web development pop up every week and…

Very good list of some issues that lead to "the new hotness" all the time. I had not thought of some of these; it's not totally brain-dead fanboyism.

One issue that (good) bosses have is that they cannot allow their business to be held hostage by one person. If that person quits (or dies), they have to be able to replace them. Esolangs are a hard sell on that basis alone, no matter how fit for use they may be.

I'd forgotten Clojure (and others!) - yes, Lisp is more popular than "things named Lisp". And, arguably, Clojure is popular enough these days that the argument in the previous paragraph doesn't really apply to it any longer. (Whether bosses know that is a separate issue.)

Then there's the claim by Guy Steele that, in creating Java, he dragged a bunch of C++ programmers "halfway to Common Lisp". (Lisp purists might concede some fraction considerably less than half...) Paul Graham says that the Lisp feature set is slowly taking over programming languages. Lisp may die but still conquer, or mostly conquer.

Re: On Getting Older in Tech

#384

Post by lisper » Sat, Dec 10, 2016, 1:41 AM UTC

AnimalMuppet wrote: post #379

lisper wrote: post #375

Earlier quoted context omitted.

You are overlooking a crucial fact: very often people who want to use Lisp are not allowed to by their management precisely because "no one uses it" and so the experiment never gets done. I was the lead engineer on the first release of AdWords. I wanted to write it in Lisp, but I was not allowed to, being forced against my strenuous objections to to it in Java. So now AdWords is a Java success story rather than the L…

If that were the (only) issue, we ought to see Lisp used more in startups than in established businesses, because in startups, you don't have some manager who doesn't know Lisp and is managing to minimize is perceived (not necessarily actual) technical risk. But in fact I'm not sure that we see more Lisp use in startups, either. That could be because they aren't taught it in school. (Many startup founders haven't had…

It's all a viscous cycle going back to AI winter in the late 80's: DARPA stopped funding AI work, which meant that funding for Lisp work dried up, which meant that fewer people used it, which meant that fewer people learned it. Now, 30 years later, hardly anyone uses it, at least not directly. But it keeps getting re-invented again and again. You can't avoid re-inventing Lisp because it's part of the fundamental physics of computing. That is my frustration. People say that Lisp sucks, and then they proceed to re-invent it badly not even being aware that that is what they are doing.

As to why the re-implementation of the Remote Agent (it wasn't the whole thing BTW, just the planner) in C++ failed, it was a combination of factors. This was twenty years ago (holy cow!) and C++ compilers were nowhere near as mature then as they are now. There was only one compiler available for the flight hardware, and it was pretty unstable. But mainly it was Greenspun's tenth: the application did a lot of dynamic allocation (it was an AI search algorithms) which is something C++ is particularly not well suited for. They essentially had to re-implement Lisp in C++, and that was hard. Of course it would have been possible given more time, but we didn't have more time. The Lisp code was working, so that's what we flew.

Re: On Getting Older in Tech

#385

Post by lispm » Sat, Dec 10, 2016, 1:49 AM UTC

AnimalMuppet wrote: post #383

lispm wrote: post #367

Earlier quoted context omitted.

Lisp is old and it's unlikely that you see hype anytime soon. But you can see that Lisp derived languages like Clojure can generate minor hypes. Other new languages may even contain substantial pieces of Lisp influence. Examples would be Julia or R. Generally the industry has problems reusing old/existing technology. See for example the Javascript domain, where new frameworks for web development pop up every week and…

Very good list of some issues that lead to "the new hotness" all the time. I had not thought of some of these; it's not totally brain-dead fanboyism. One issue that (good) bosses have is that they cannot allow their business to be held hostage by one person. If that person quits (or dies), they have to be able to replace them. Esolangs are a hard sell on that basis alone, no matter how fit for use they may be. I'd fo…

What Java mostly got from Lisp was parts of memory model and the managed memory, not so much on the language side. Smalltalk got that from Lisp too. Ruby also (the Ruby developer studied the Emacs Lisp implementation). Microsoft's CLR also. Actually parts of the early Microsoft .net CLR GC were written in Lisp and automatically translated to C.

But Java could not do a lot of things a typical Lisp implementation can do, sometimes with a good reason for that.

  * runtime compilation
  * loading of code (-> custom class loader)
  * garbage collection of code is sometimes difficult
  * saving/starting of memory dumps
  * fast startup times
  * tail call optimization
  * updating changed objects
  * calling error system -> Java has a terminating error system

For most of these problems some 'solutions' have been developed. On the language level the Java community experimented with some original Lisp stuff, too. But not much was added to the language, but at least they got lambda expressions (1958 in Lisp) and a first kind of multiple inheritance of code (around 1980 in Lisp via Flavors). Java soon will have a standard shell for incremental use ( https://blogs.oracle.com/java/jshell-and-repl-in-java-9 ) - that was around 1960 in Lisp. Now imagine when Macros will be added...

But generally knowing Lisp does not help you much with Java, since the language's OOP model is very different from the typical OOP in Lisp (see CLOS+MOP).

Re: On Getting Older in Tech

#386

Post by AnimalMuppet » Sat, Dec 10, 2016, 1:53 AM UTC

lisper wrote: post #384

AnimalMuppet wrote: post #379

Earlier quoted context omitted.

If that were the (only) issue, we ought to see Lisp used more in startups than in established businesses, because in startups, you don't have some manager who doesn't know Lisp and is managing to minimize is perceived (not necessarily actual) technical risk. But in fact I'm not sure that we see more Lisp use in startups, either. That could be because they aren't taught it in school. (Many startup founders haven't had…

It's all a viscous cycle going back to AI winter in the late 80's: DARPA stopped funding AI work, which meant that funding for Lisp work dried up, which meant that fewer people used it, which meant that fewer people learned it. Now, 30 years later, hardly anyone uses it, at least not directly. But it keeps getting re-invented again and again. You can't avoid re-inventing Lisp because it's part of the fundamental phys…

Supposing the AI winter never happened, what is your perception of where Lisp would be now? Dominant? Large niche? Small niche, but larger than present?

Re: On Getting Older in Tech

#387

Post by lisper » Sat, Dec 10, 2016, 2:02 AM UTC

AnimalMuppet wrote: post #386

lisper wrote: post #384

Earlier quoted context omitted.

It's all a viscous cycle going back to AI winter in the late 80's: DARPA stopped funding AI work, which meant that funding for Lisp work dried up, which meant that fewer people used it, which meant that fewer people learned it. Now, 30 years later, hardly anyone uses it, at least not directly. But it keeps getting re-invented again and again. You can't avoid re-inventing Lisp because it's part of the fundamental phys…

Supposing the AI winter never happened, what is your perception of where Lisp would be now? Dominant? Large niche? Small niche, but larger than present?

I have no idea, and it doesn't really matter because we can't go back. I really don't want to dwell on the past, except insofar as we can learn lessons that inform the future. The point I really want to make is that Lisp is still a viable option today (Common Lisp and Clojure in particular) and I would like to see people give it a fair shake going forward.

Re: On Getting Older in Tech

#388

Post by collinmanderson » Sat, Dec 10, 2016, 3:09 AM UTC

myth_drannon wrote: post #301

Lambdanaut wrote: post #269

Earlier quoted context omitted.

Dude. Open source software.

Even jQuery which is one of the most famous open source projects will be forgotten in 10 years or even less.

jQuery is _still_ in html5 boilerplate, which I consider to be a good simple starting point for content-based websites. https://html5boilerplate.com/

Re: On Getting Older in Tech

#389

Post by matwood » Sat, Dec 10, 2016, 3:24 AM UTC

rifung wrote: post #354

matwood wrote: post #309

Earlier quoted context omitted.

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…

If everything else is equal, then obviously knowing the current language I need will push that person ahead. IME, the language(s) a senior person knows is the least important part whether they are a good hire though.

My reasoning for this is that we are always learning new languages and using new frameworks. Why would I let a better person go when the language is probably going to change, or worst case they pick it up in a couple weeks just by looking at the existing code base? One case where I would deviate a bit is if I was hiring for a functional programming position. In that case I would prefer experience with some functional language, but that is not much different than wanting OO experience for a Java/C# position.

Re: On Getting Older in Tech

#390

Post by kazinator » Sat, Dec 10, 2016, 7:21 AM UTC

lisper wrote: post #373

kazinator wrote: post #351

Earlier quoted context omitted.

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…

> Why would I want implicit laziness everywhere? For the same reason you want automatic memory management: so you can fob off the job of figuring out where the thunks should go onto the compiler, just as you fob off the job of figuring out where the calls to malloc and free should go. At least that's the theory. It seems plausible to me. I think it's an open question whether my failure to grok Haskell is due to a pro…

It's not the same. Here is why: the program correctness doesn't depend on when (or even whether!) that automatic memory management happens. Lisp systems have been bootstrapped without having a working garbage collector upfront. Short-lived Lisp images run as processes in a conventional OS might never have a chance to collect garbage.

Laziness has precise semantics which has to unfold properly, or else things don't work.

Delaying evaluation is not the same thing as delaying reclamation. They are opposite in a sense, because we only allow something to be reclaimed when it is "of no value".