What Programming Languages do you use?

[whartung]

I tried python long ago, it didn't stick. I don't care for it now.

I haven't done enough Ruby to judge.

Go looks compelling, but have not had an application that I've wanted to do with it (well, I do, but the necessity of it has fallen off).

Perl is dead to me. Every time I wanted to use it and required something out of CPAN, it's basically been a disaster, and I just throw up my hands.

AWK is my go to utility language, has been since forever. I really like AWK.

For everything else, I use Java. Java is my "cold, dead, hands" language.

Ya know what I like about Java? I like the locality of it. Outside of the JVM, I simply don't have to worry about some centralized dependency hell walking all over my code and my build. On the one hand, I have Maven, and it's versioned central repository, and on the other, I can simply copy my jars local to my code base, and link 'em all up in a bundle, and stay in my little sandbox. Maven's versioning is mostly bullet proof, and I don't have to worry about dependencies on libThis or libThat, downloading eleventy different Not Java packages and projects just to get my Java to work.

For example, Java has it's own SSL stack, and no dependency on OpenSSL. A simple thing, but on a linux box, E V E R Y T H I N G depends on OpenSSL. So, if you get Project Y that wants the Latest McGreatest version of OpenSSL (or whatever), then next thing you know you're on Windows 12 just because you updated Python.

Java is a sandbox, it doesn't download the internet and make global changes to your system to write a 10 line character generator.

It's...just...that much easier.

Java is Java.

I don't know how Go fits in that world.

 

[Leitz]

I don't know how Go fits in that world.

Go is a compiled language, and you can import stdlib packages like "fmt" (for print statements, etc). You can also get external third-party libraries that get copied into your package's workspace and compiled into your program. Once in the workspace I haven't see it try to reach out and get a newer version or anything.

Go does have an attitude. You can't import something and not use it. You can't declare a variable and not use it, the code just won't compile. Go is about the data, and is more "object based" than "object oriented". There's no inheritance, you get a sort of polymorphism with Interfaces.

So, interfaces took me a bit to get, but here's a rough idea. An "object" in Go is basically a struct. You declare methods and associate them with the struct. What makes this a little different is the struct doesn't really know if you attached a method to it or not. An example may be worth a thousand doc strings:

// All programs start with this. Libraries declare themselves by package name.
package main

// Import the "fmt" package, which has the Print commands. 
import (
  "fmt"
)

// Standard function declaration.
func sayHiToGuest (guest string) {
  fmt.Printf("Hello %s!\n", guest)
}

// Define our stuct to store data. 
type Person struct {
  name  string
}

// Define the method sayHiToFriend and attach it to a struct of type Person.
// Note that the struct itself doesn't have to change.
func (person *Person) sayHiToFriend() {
  // Using a different Print variant, just to show it off.  :)
  fmt.Println("Hey", person.name, "good to see you again!")
}

// Standard "main", just like C. No return values.
func main(){
  // The := is a shortcut declare and assign. 
  // Only works in functions, and main is a function.
  myGuest := "D&D Player"
  sayHiToGuest(myGuest)
 
  
  // Create the Person, with a name, and assign to "myFriend". 
  myFriend := Person{ name: "whartung" }
  myFriend.sayHiToFriend()
}

In this case the Person has a name. An interface has a "method set", anything that implements that method set can be used with that interface. For example, say we made an Interface that implemented an "origin" method. We then create structs of types Person, Droid, and Ship. The Person.origin method might give home world, the Droid might give factory name, and the Ship could give fleet designation. How something implements "name" is irrelevant, as long as it does.

Hope that helps. If you like, you can cut and paste the code in the Go playground and fiddle with the bits to see what happens. The code actually runs if you get everything between the code markers.

 

[whartung]

Go is a compiled language, and you can import stdlib packages like "fmt" (for print statements, etc). You can also get external third-party libraries that get copied into your package's workspace and compiled into your program. Once in the workspace I haven't see it try to reach out and get a newer version or anything.

Yea, I was just curious how dependent Go libraries are on non-Go libraries.

Things like python and ruby do a LOT as simply wrappers to standard libraries of C code, whereas Java tends to re-write everything. Wasn't sure where Go was on that spectrum.

 

[Leitz]

Yea, I was just curious how dependent Go libraries are on non-Go libraries.

Things like python and ruby do a LOT as simply wrappers to standard libraries of C code, whereas Java tends to re-write everything. Wasn't sure where Go was on that spectrum.

Hmm...not sure. I *think* Go only uses Go stuff, not openssl this or libffi that. That said, I really don't know. I'll ask on IRC though, and see what folks say.

 

[Leitz]

Answer seems to be that Go is a "Use only Go stuff" type thing, unless you really make the effort. Unlike Java, there's no VM underneath. You're pretty much as close to the machine as C.

 

[Ullarsskald1957]

Last time I did any programming, used machine language and Forth.
It's been about 20 years.

Learned Fortran in college (43 years ago) before I learned Basic.

 

[agorski]

Last time I did any programming, used machine language and Forth.
It's been about 20 years.

Learned Fortran in college (43 years ago) before I learned Basic.

I learned Fortran in college 49 years ago and then dabbled as a hobbyist in assembly language and Forth before working on flight simulators using assembly language and Fortran.

These days I use Xojo for my iOS apps.

 

[willtron3030]

I learned Fortran in college 49 years ago

Out of curiosity, who taught hour FORTRAN class? I think there were two or three possibilities back then.

As for FORTH, dabbled? You wrote your own Apple II FORTH kernel, IIRC.

 

[agorski]

Out of curiosity, who taught hour FORTRAN class? I think there were two or three possibilities back then.

As for FORTH, dabbled? You wrote your own Apple II FORTH kernel, IIRC.

Man, I have no idea who my professors were back then, except for my advisor.

I bought a 6809 processor card for my Apple ][ and ran a purchased copy of 6809 Forth on that. So all I had to write was the 6502 code that interfaced that to the Apple's I/O. Not too hard.

Wire-wrapped a parallel PIA card for the Apple and wrote code to print to a surplus I/O Selectric typewriter. Never could get that to work reliably. My hardware skills were minimal.

I still own all of this hardware and software so if someone knows of a good museum in need of some early stuff, let me know. My Apple is the first production run with Integer Basic, serial number 660. The disk drive is serial number 345. Also have Visicalc in the box.

 

[Leitz]

Forty seven years ago I was figuring out what all the "kiss a girl" fuss was about. Still learning but the research is fun. Computers take a distant second place. :rofl:

 

[FreeTrav]

I tend to write PowerShell (which qualifies as a .NET language, though it's now available cross-platform as PowerShell Core and .NET Core) and QBASIC, most often in the form of QB64 (see QB64.org). I can read a whole hell of a lot more, and can and have debugged most of them (partial list: GWBASIC, Pascal, Modula-2, PL/1, C, C++, C#, Visual BASIC, APL, PILOT, LISP,COBOL, FOCAL, COMAL).

 

[FreeTrav]

There are also Z-machines for Android, and while I can't find it now, I'd swear I even saw one for UCSD P-System II...

 

[Leitz]

Yea, I was just curious how dependent Go libraries are on non-Go libraries.

Things like python and ruby do a LOT as simply wrappers to standard libraries of C code, whereas Java tends to re-write everything. Wasn't sure where Go was on that spectrum.

Sorry for the repeat answer, I'm not trying to sell Go. It's free.

Attended a cool CI/CD webinar on Go today. There's a free tool that cross-compiles binaries; that is, Go binaries don't require much of anything on the target host. Just drop in the binary and run it. You don't even need Go on your machine.

 

[whartung]

Sorry for the repeat answer, I'm not trying to sell Go. It's free.

Attended a cool CI/CD webinar on Go today. There's a free tool that cross-compiles binaries; that is, Go binaries don't require much of anything on the target host. Just drop in the binary and run it. You don't even need Go on your machine.

Oh, no, I appreciate the information. Go is interesting I just haven't had a chance to look at it in any detail. From afar, I like it's enforced patterns, and One Way for things like projects, and building, and other pre-made choices that make things easier for people like me who loathe detail.

I care about A build environment, not necessarily a PARTICULAR build environment.

I like how Go has incorporated much of the entire cycle in to the system, it's not just syntax and a compiler.

 

[aramis]

There are also Z-machines for Android, and while I can't find it now, I'd swear I even saw one for UCSD P-System II...

Here's the list from inform-fiction.org:

Amiga
Amstrad
Apple II
Atari ST
BeOS
DOS
GEM
Mac OS
Newton
Oric
OS/2
RISC OS
Spectrum
Unix
Windows
eBookman
EPOC
Gameboy
Helio
Nokia
PalmOS
Psion
TI
Windows CE
Wizard
Emacs
Java
Javascript​

Note that windows versions go back to 3.0 or earlier, and up through win 10 on both architectures.
I've used Palm and android versions...

 

[Leitz]

Oh, no, I appreciate the information. Go is interesting I just haven't had a chance to look at it in any detail. From afar, I like it's enforced patterns, and One Way for things like projects, and building, and other pre-made choices that make things easier for people like me who loathe detail.

I care about A build environment, not necessarily a PARTICULAR build environment.

I like how Go has incorporated much of the entire cycle in to the system, it's not just syntax and a compiler.

Well, sometimes the strictures are a pain. That said, my "crewgen" code actually serves up a semi-dynamic web page without Apache, etc. The Go standard library has http server code and uses a routing process similar to Sinatra. The only thing I'm using outside of the Standard Library is the SQLite driver. Pretty cool stuff, and not a lot of code. The entire web app and server is wrapped up in the one package and hosted on Google App Engine. The same code also runs locally if you prefer that.

 

[whartung]

Well, sometimes the strictures are a pain.

How's that?

 

[Leitz]

How's that?

Seriously static typing (int, int8, int16, int64) and not being able to pass a value to a method unless it is the right type.

Go checks the code before it compiles. If you include a library but don't use it, Go doesn't complain. It absolutely whines and refuses to compile. Same if you declare a variable but don't use it.

Those are the ones that usually get me, but I'm not doing any deep coding yet, either.

 

[willtron3030]

It's funny because it's true

[Disclaimer: I use perl when appropriate]

93% of paint splatters are valid perl programs

 

[77topaz]

[Disclaimer: I use perl when appropriate]

93% of paint splatters are valid perl programs

Yeah, and even just parsing Perl code is a task equivalent to the halting problem.