• Welcome to the new Internet Infidels Discussion Board, formerly Talk Freethought.

The Programming Thread

Ways in which the mental exertion required for programming are analogous to the exertion required for physical work:

These days I notice when I've reached my mental limit. If I code hard and long enough eventually I reach a point where I simply cannot anymore. Yesterday this happened around mid-afternoon and I started struggling to get anything done. So I took the rest of the day off to relax and start again this morning.

And this morning, with a fresh mind, I came in and solved a problem I was struggling with yesterday in roughly 10 minutes.

Yup. You can spend more time writing code but it won't produce more useful code.
 
Been coding since the 1970's. did it professionally for a multi-billion dollar software company that everyone has heard of. Moved into Security and only script professionally for data collection and analysis.

for fun, I've been coding in all sorts of languages... Currently, I am using Unreal Engine 4 to develop VR games... for myself. nothing commercial (yet).
Since Epic changed their licensing scheme, I highly recommend anyone interested in gaming and coding check it out. It is FREE to use. If you sell something using the engine, then you pay them 7% of profits as royalty.

It is C++ at its core (and fully integrated with visual studio, github, all that).. BUT, (huge but), it is a visual implementation... you don't type a thing. All drag and drop nodes and connections between nodes to express the code.

Instead of

If A > B Then
Begin
End
Else
Begin
End


It is a "Branch node" with a Boolean input and two execution paths for true or false.

Just google "UE4 Blueprint" and look at the images.
 
I'm retired now, so I haven't done much programming for a couple of years. I started with FORTRAN in the 1960s but didn't enjoy working with punch cards. However, I came back to it in the 1970s while teaching Linguistics at Columbia University and had auditing privileges in any university courses I desired. So I was able to get a second education in computer science courses, which introduced me to some standard languages of the time: BASIC, Pascal, LISP, Assembler, etc. Given my main interests--Natural Language Processing and Artificial Intelligence--I came to really enjoy programming in LISP, the mainstay of that field. LISP, the oldest programming language that is still in productive use, remains my favorite, although I've programmed in lots of other languages including PROLOG. I've also worked a with Perl, Tcl, other scripting languages, and application interface languages (e.g. Arbortext and Framemaker code).

Although I've written quite a few programs and contributed to quite a few advanced projects, my main application was a natural language parser that served as the main engine in a major commercial grammar checking application (the Boeing Simplified English Checker). We used that code in many projects over the years, but it is at the end of its life, given that just about everyone who ever worked on it is now retired or about to retire. The parser itself is still among the best syntactic parsers in existence, given that we ran very high volumes of raw text through it over the 25 years that I worked on it. Most such parsers are academic projects with very short lifespans, so they don't provide the same level of coverage for English syntax. The Boeing parser is written and compiled 100% in Lispworks' brand of Common Lisp.
 
LISP: Lots of Irritating Superfluous Parentheses

I think that Fortran likely beats it as the oldest high-level language currently in use. But these days, it's mostly used for number crunching. Even so, most high-level languages in use have a rather Fortran-like appearance. Even those with lots of LISP-like features.
 
LISP: Lots of Irritating Superfluous Parentheses

EMACS removes the irritation. Its automatic paren-balancing and indentation makes programming in LISP very easy and intuitive.

I think that Fortran likely beats it as the oldest high-level language currently in use. But these days, it's mostly used for number crunching. Even so, most high-level languages in use have a rather Fortran-like appearance. Even those with lots of LISP-like features.

You are right. Fortran is one year older (1957). I might be remembering incorrectly, but I thought that one of the profs at Columbia had claimed that only COBOL was older than LISP. In any case, COBOL is largely retired now. Fortran may still be in use, but probably not as actively as LISP, which still dominates knowledge-based AI programming.

Logo was a so-called children's programming language, but it was largely a simplified version of LISP in which most of the parentheses were removed and some of the obscure functions (CAR, CDR, etc.) were replaced with more transparent labels (FIRST, BUTFIRST, etc.). Python is also something of a LISP knock-off. It even has lambda expressions.
 
LISP: Lots of Irritating Superfluous Parentheses

I think that Fortran likely beats it as the oldest high-level language currently in use. But these days, it's mostly used for number crunching. Even so, most high-level languages in use have a rather Fortran-like appearance. Even those with lots of LISP-like features.

There are new dialects of LISP making resurgences. Consider the Clojure on the JVM. Clean, concise functional code with access to libraries written in Java. From what I understand, it's more useful than Common Lisp ever got to be, by virtue of being in the JVM world. There's even Clojurescript, a compiler that emits Javascript from Clojure.
 
LISP: Lots of Irritating Superfluous Parentheses

I think that Fortran likely beats it as the oldest high-level language currently in use. But these days, it's mostly used for number crunching. Even so, most high-level languages in use have a rather Fortran-like appearance. Even those with lots of LISP-like features.

There are new dialects of LISP making resurgences. Consider the Clojure on the JVM. Clean, concise functional code with access to libraries written in Java. From what I understand, it's more useful than Common Lisp ever got to be, by virtue of being in the JVM world. There's even Clojurescript, a compiler that emits Javascript from Clojure.

Actually, the two major commercial Common Lisps--Allegro and Lispworks--extended their code to talk conveniently to Java and scripting languages a few years ago. We took advantage of that in a few of our integrations with authoring systems. The big problem with LISP these days is that computer science curricula no longer treat it as a necessary component of the student's education. It is hard to find LISP programmers. So there is no longer a large population of programmers to develop and sustain LISP projects.
 
LISP: Lots of Irritating Superfluous Parentheses

I think that Fortran likely beats it as the oldest high-level language currently in use. But these days, it's mostly used for number crunching. Even so, most high-level languages in use have a rather Fortran-like appearance. Even those with lots of LISP-like features.

There are new dialects of LISP making resurgences. Consider the Clojure on the JVM. Clean, concise functional code with access to libraries written in Java. From what I understand, it's more useful than Common Lisp ever got to be, by virtue of being in the JVM world. There's even Clojurescript, a compiler that emits Javascript from Clojure.

Actually, the two major commercial Common Lisps--Allegro and Lispworks--extended their code to talk conveniently to Java and scripting languages a few years ago. We took advantage of that in a few of our integrations with authoring systems. The big problem with LISP these days is that computer science curricula no longer treat it as a necessary component of the student's education. It is hard to find LISP programmers. So there is no longer a large population of programmers to develop and sustain LISP projects.

Is that a problem? Most programmers I come across these days are generalists with the ability to shift between languages. My thing with LISP is that I've just never seen a job that required it or had any incentive to work with it.

While it sounds like they're two very different technologies, the closest analogue I can think of is COBOL. I've actually seen COBOL job postings given I work in a town with some finance companies, and while I'm confident I could handle a role working with it, I just don't want to build my skill-set in an increasingly niche area.

I could see others being the same with LISP. Why take a role working with something that's not really used anymore, when you could learn something like Ruby-on-Rails and be in high demand.
 
Actually, the two major commercial Common Lisps--Allegro and Lispworks--extended their code to talk conveniently to Java and scripting languages a few years ago. We took advantage of that in a few of our integrations with authoring systems. The big problem with LISP these days is that computer science curricula no longer treat it as a necessary component of the student's education. It is hard to find LISP programmers. So there is no longer a large population of programmers to develop and sustain LISP projects.

Is that a problem? Most programmers I come across these days are generalists with the ability to shift between languages. My thing with LISP is that I've just never seen a job that required it or had any incentive to work with it.
There is a kind of negative feedback loop going on here. When universities stopped pushing LISP as an important language to know, that generated fewer people with skills to maintain LISP code, which reduced incentive to program in LISP, which reduced incentive for people to train others to program in it, and so forth.

While it sounds like they're two very different technologies, the closest analogue I can think of is COBOL. I've actually seen COBOL job postings given I work in a town with some finance companies, and while I'm confident I could handle a role working with it, I just don't want to build my skill-set in an increasingly niche area.
COBOL is older, but it is not a general programming language. LISP is a mature, very powerful general programming language. Its code is extremely portable across most operating systems and platforms. Despite all the parentheses, the syntax is quite trivially easy to learn, and it makes the processing of linked lists extremely easy. It handles memory space and garbage collection very well. It comes native as an interpreted language, but one can generate very efficient standalone runtime applications with it. Hence, it is easier to debug than most programming languages that require special environments and tools for that purpose.

I could see others being the same with LISP. Why take a role working with something that's not really used anymore, when you could learn something like Ruby-on-Rails and be in high demand.
I agree. If you aren't writing programs that process language or knowledge structure, then it makes a lot more sense to go with languages for which there is a broad community of support. That used to be the case with LISP, but it is now an obscure language that most young programmers never come into contact with.

Back in the 90s and early 2000s, we had a lot of trouble with our all-LISP natural language program. Boeing wanted to use it in a wide range of applications, but procurement lost the ability to order and pay for licenses. We had to find high level management backing to help cut all the red tape that was blocking our ability to maintain it. At one point, several managers wanted us to convert the code to a "standard" programming language such as C, even though C and C+ at the time was less portable and less easy to debug. They allocated a hefty amount of money to purchase a one-off license for a lisp-to-C converter, not to mention our labor in trying to make the thing work as a production level process. Hence, we had to maintain both the LISP code and the generated C code, which always ended up with glitches in it. Eventually, those managers were rewarded for their successful efforts at converting us to orthodoxy and promoted to other endeavors. At that point, we dropped the C conversion and went back to generating runtime applications with just LISP at much reduced cost for all platforms. We never looked back, and the program still runs fine on most platforms. Integration with large (usually Arbortext) authoring systems was trivial--just one line of code in the customization section and a small, easily configurable wrapper file for handshakes with the host system.
 
EMACS removes the irritation. Its automatic paren-balancing and indentation makes programming in LISP very easy and intuitive.
Have you tried "paredit"? I can't write Lisp code anymore without it.

Structured editing has always been this dream among some code editor folk, but I've only ever seen it work for Lisp.

You are right. Fortran is one year older (1957). I might be remembering incorrectly, but I thought that one of the profs at Columbia had claimed that only COBOL was older than LISP. In any case, COBOL is largely retired now. Fortran may still be in use, but probably not as actively as LISP, which still dominates knowledge-based AI programming.
COBOL is definitely not older than Lisp, but I believe it was the first ever compiled language. I also think Lisp existed on paper in 1957. The story is that McCarthy wasn't trying to write a programming language: he was trying to come up with a better formalism for metalogic.
 
Is that a problem? Most programmers I come across these days are generalists with the ability to shift between languages.
C++ was designed to be easy for C programmers to shift to. Java was designed for C++ programmers to shift to. C# was designed for Java programmers to shift to, going so far as to implement blatant mistakes in the type system so as not to confuse Java programmers. Even Javascript, which is semantically completely different, still makes itself comfortable syntactically to the ALGOL derivatives. I take this as evidence that language designers think that programmers are not generalists, and are mostly scared of new things. I don't think they're wrong.

Programmers think they're generalists, but most often they're moving between languages that don't take much effort to move between. Get me the programmer who is competent in C, competent in Prolog, competent in Lisp and competent in Haskell, and I'll call them a generalist.
 
Last edited:
There's a great essay by the Lisp hacker Dick Gabriel from the late 90s partly explaining how Lisp had its downfall in academia. His claim is that academia stopped caring about programming languages as systems/environments, and started seeing them as inputs to UNIX compilers.

One of the most popular academic languages in computer science is Haskell, which, in terms of being a system/environment, is a shocking step backward. There are awesome stories of Common Lisp runtimes persisting for months and years in production: when there's a bug, the developer remotes in, gets to the error condition, and patches the code live. This is a concept that runs right through Lisp: it knows it's capable of being an operating system and that's what it wants to be. Lisp machines used to be Lisp down to the hardware. The closest I have to this now is Emacs, which I am more than happy to see devour my entire computer and reign supreme. (once the Cairo backend is stable, there's not much it won't be able to do)

Your average Haskell REPL barely lasts a minute. It's a language that's mostly designed to feed a compiler to produce a binary that you never again interact with as a developer. This makes me super sad (and I love Haskell).
 
There is a kind of negative feedback loop going on here. When universities stopped pushing LISP as an important language to know, that generated fewer people with skills to maintain LISP code, which reduced incentive to program in LISP, which reduced incentive for people to train others to program in it, and so forth.

While it sounds like they're two very different technologies, the closest analogue I can think of is COBOL. I've actually seen COBOL job postings given I work in a town with some finance companies, and while I'm confident I could handle a role working with it, I just don't want to build my skill-set in an increasingly niche area.
COBOL is older, but it is not a general programming language. LISP is a mature, very powerful general programming language. Its code is extremely portable across most operating systems and platforms. Despite all the parentheses, the syntax is quite trivially easy to learn, and it makes the processing of linked lists extremely easy. It handles memory space and garbage collection very well. It comes native as an interpreted language, but one can generate very efficient standalone runtime applications with it. Hence, it is easier to debug than most programming languages that require special environments and tools for that purpose.

I could see others being the same with LISP. Why take a role working with something that's not really used anymore, when you could learn something like Ruby-on-Rails and be in high demand.
I agree. If you aren't writing programs that process language or knowledge structure, then it makes a lot more sense to go with languages for which there is a broad community of support. That used to be the case with LISP, but it is now an obscure language that most young programmers never come into contact with.

Back in the 90s and early 2000s, we had a lot of trouble with our all-LISP natural language program. Boeing wanted to use it in a wide range of applications, but procurement lost the ability to order and pay for licenses. We had to find high level management backing to help cut all the red tape that was blocking our ability to maintain it. At one point, several managers wanted us to convert the code to a "standard" programming language such as C, even though C and C+ at the time was less portable and less easy to debug. They allocated a hefty amount of money to purchase a one-off license for a lisp-to-C converter, not to mention our labor in trying to make the thing work as a production level process. Hence, we had to maintain both the LISP code and the generated C code, which always ended up with glitches in it. Eventually, those managers were rewarded for their successful efforts at converting us to orthodoxy and promoted to other endeavors. At that point, we dropped the C conversion and went back to generating runtime applications with just LISP at much reduced cost for all platforms. We never looked back, and the program still runs fine on most platforms. Integration with large (usually Arbortext) authoring systems was trivial--just one line of code in the customization section and a small, easily configurable wrapper file for handshakes with the host system.

I guess the question then is what caused universities to stop promoting it? I'd assume it's features were becoming obsolete, but that's a real question, I don't know anything about the language.
 
Is that a problem? Most programmers I come across these days are generalists with the ability to shift between languages.
C++ was designed to be easy for C programmers to shift to. Java was designed for C++ programmers to shift to. C# was designed for Java programmers to shift to, going so far as to implement blatant mistakes in the type system so as not to confuse Java programmers. Even Javascript, which is semantically completely different, still makes itself comfortable syntactically to the ALGOL derivatives.

Programmers think they're generalists, but most often they're moving between languages that don't take much effort to move between. Get me the programmer who is an expert in C, an expert in Prolog, and an expert in Haskell, and I'll call them a generalist.

I think your key word there is 'expert'. Becoming an expert in anything takes time/effort, and so if you get into programming with languages like C++/Java that's where your expertise will lie, but that doesn't mean you can't transition into something a bit removed as a beginner and quickly get up to speed.

I think you'll find few people who are experts as such at a wide variety of languages/frameworks. But you will find people with a broad understanding of programming who can pick up any given language in a couple months, given the opportunity to commit some time to learning it.

Granted people who are good at this are rare, but that's because good programmers are rare no matter where you're looking.
 
I guess the question then is what caused universities to stop promoting it? I'd assume it's features were becoming obsolete, but that's a real question, I don't know anything about the language.
See my previous post. I don't have the link, but it was specifically Gabriel complaining about the International Conference of Functional Programming, which he reckons went from being a Lisp focused conference to being a toy compiler conference.

I don't think all is lost. At my university. Haskell and Standard ML were ubiquitous, and there was a sense that both were Lisp but better. I don't entirely agree with this, but they've got a decent claim to the tradition. The first implementations of both languages were written in Lisp, and had some native interop with the host Lisp system. Standard ML is still very Lispy, and Copernicus might be pleased to know that its programmers still use the equivalent of save-lisp-and-die.

- - - Updated - - -

I think your key word there is 'expert'.
Yeah :) I preempted this reply so dialed down to "competent." I think my point still stands that there are hardly any generalists.
 
I guess the question then is what caused universities to stop promoting it? I'd assume it's features were becoming obsolete, but that's a real question, I don't know anything about the language.
See my previous post. I don't have the link, but it was specifically Gabriel complaining about the International Conference of Functional Programming, which he reckons went from being a Lisp focused conference to being a toy compiler conference.

I don't think all is lost. At my university. Haskell and Standard ML were ubiquitous, and there was a sense that both were Lisp but better. I don't entirely agree with this, but they've got a decent claim to the tradition. The first implementations of both languages were written in Lisp, and had some native interop with the host Lisp system. Standard ML is still very Lispy, and Copernicus might be pleased to know that its programmers still use the equivalent of save-lisp-and-die.

- - - Updated - - -

I think your key word there is 'expert'.
Yeah :) I preempted this reply so dialed down to "competent." I think my point still stands that there are hardly any generalists.

My meaning of generalist was more along the lines of being adaptable, but now that I think of it you may be right that true, strong generalists may be rare.

I might be a bit biased because I come from a college program that pumped out a lot of them, but the same program had about three times as many drop-outs. The scene around the companies I've worked for hasn't been much better. The strong programmers have been an exception rather than the rule.
 
EMACS removes the irritation. Its automatic paren-balancing and indentation makes programming in LISP very easy and intuitive.
Have you tried "paredit"? I can't write Lisp code anymore without it.

Structured editing has always been this dream among some code editor folk, but I've only ever seen it work for Lisp.
I've never used Paredit. I have tried other editors and editing environments, but I always came back to Emacs, which I still use for just about every text editing activity, even HTML/CSS editing.

You are right. Fortran is one year older (1957). I might be remembering incorrectly, but I thought that one of the profs at Columbia had claimed that only COBOL was older than LISP. In any case, COBOL is largely retired now. Fortran may still be in use, but probably not as actively as LISP, which still dominates knowledge-based AI programming.
COBOL is definitely not older than Lisp, but I believe it was the first ever compiled language. I also think Lisp existed on paper in 1957. The story is that McCarthy wasn't trying to write a programming language: he was trying to come up with a better formalism for metalogic.

You are right about COBOL being younger than LISP, so it was FORTRAN and LISP that are the two oldest programming languages still in use. Grace Hopper started working on English-based programming interfaces back in the 1940s, however. COBOL basically developed out of her previous approaches.
 
I've never used Paredit. I have tried other editors and editing environments, but I always came back to Emacs, which I still use for just about every text editing activity, even HTML/CSS editing.
Awesome! I tend to live in Emacs, too. Paredit is just an Emacs mode.

I'm coding Java day-to-day and I'm not sure Emacs is anywhere near as up to that task as IntelliJ, at least right now. It needs a decent SLIME style architecture so it can chat with a real compiler/runtime backend.
 
Had one of those weeks this week where my mind is mush by Friday. Looks like I'll have to put off any further thinking until tomorrow.
 
Back
Top Bottom