371–380 of 440 posts
Article mentions "RPG" many times: "RPG back-end", "RPG developer". For those who wonder what it it (like me), it is not a "Role Playing Game", it is IBM RPG language: https://en.wikipedia.org/wiki/IBM_RPG
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…
Earlier quoted context omitted.
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…
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 problem with Haskell or the ossification of my brain.
Earlier quoted context omitted.
> 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
Good cite. (Although the fact that some people can make successful Common LISP software could just be that those people are exceptional enough to make successful software in any language, it doesn't bolster the claim that 'Common LISP is one of the best choices for many applications' very strongly).
If you would run a Cement plant, an oil pipeline or a coal terminal in South Africa, then you might also be using G2 to control and diagnose technical processes in real-time.
The product used, written in Lisp:
Earlier quoted context omitted.
>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…
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 Lisp success story it might have been not because Java is better (it certainly wasn't -- it was a disaster) but because my boss issued an edict.
This has happened to me many times in my career. The one time I was actually allowed to use Lisp in a project that I did not have direct control over (the DS1 remote agent) it was an overwhelming technical success. In fact, management tried and failed to get the software rewritten in C++, so this was actually a controlled experiment.
Earlier quoted context omitted.
I would even say they favor people who have been cramming algo-on-the-whiteboard type of questions. I mean, there are several businesses built around this (CtCI, leetcode, ...) I know some North American universities have adapted to the practice and are now preparing students, but I assume this is relatively new. My algo and DS classes weren't about cramming at all. Now to be fair, reasonable companies will focus on…
Since everyone knows what they're getting into with a tech interview, I don't see why it's such a bad metric. Many companies purposefully give you a rubric/criteria to study. It's a good way of measuring whether a candidate can take the time to learn/prepare a specific set of knowledge, and then work through problems in a way that includes the interviewer (ie. other devs if hired) in the steps to solve the problem.
And how isn't that a terrible metric? Most of my current coworkers would fail as they simply don't have the time.
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…
To what degree do you use Lisp as an FP language? As a pure FP language? The forced purity may make Haskell a very different language.
And, to return to your original complaint: If you dislike new languages, I bet XML drives you straight up the wall...
Earlier quoted context omitted.
I guess you're allowed to dislike a fact, but any particular reason you dislike this particular fact?
Because it isn't a fact? There's definitely an age bias outside of Silicon Valley as well.
What this all boils down to, is if SF/SV is going to be seen as the beacon of software development, it is almost worse to me if it is ageism is being exemplified there. To give a rather rough corollary, consider if Washington D.C. never hired another underrepresented group, such as females, or minorities. It's sort of like, "well maybe I halfway, sadly expect that to happen in some small town somewhere", but C'mon! D.C.! Everyone's looking to you!" -- Same kind of thing.
Earlier quoted context omitted.
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…
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…
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 the chance to pick it up on the job. For that matter, many programmers haven't had the chance to pick it up on the job.)
On the controlled experiment: Why was that? I mean, it has to be possible to rewrite anything in C++ (Turing complete, and all that - but possibly at the price of Greenspun's Tenth Law). Was it because the people who tried didn't know anything about Lisp? (Were they working from the source, or from the spec, or from the program documentation?) Were they just not as good programmers as the Lisp programmers (and don't say "if they were as good, they would have been using Lisp" - that wasn't their assignment). Did they have less time, less resources? Why didn't/couldn't they do it?
Earlier quoted context omitted.
> 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…
Not trying to troll you here... To what degree do you use Lisp as an FP language? As a pure FP language? The forced purity may make Haskell a very different language. And, to return to your original complaint: If you dislike new languages, I bet XML drives you straight up the wall...
It depends on what I'm doing, but I generally write in an OO style more than a functional style. Real problems have state.
> If you dislike new languages
I want to be clear that this is just a general observation. I don't dislike new things because they are new, I tend to dislike them because they are generally bad. But they are not all bad. Clojure is cool. WebASM is very cool. The work that has been done on Javascript compilers is nothing short of miraculous (even though the language itself still sucks).
> I bet XML drives you straight up the wall
Kind of, but not really. Yes, I dislike XML because it is nothing but S-expressions with a more complicated syntax. But it doesn't drive me up a wall because when I need to deal with XML I just parse it into S-exprs, do what I need to do, and render the results back into XML.