Hacker News Reader

Comment by zero_shift | Hacker News Reader

Using any language for twenty years straight is going to make you complacent - but goodness, how many languages would have given you that luxury?

View on HN

The APL / J / K family of languages seems to be very strong with this effect. If it fits your problem domain, it's (apparently) so powerful that using anything else feels like a frustrating waste of time.

Yep, every time I have to program C# it is an annoyance; so much scrolling, so much text...

There's more to it; The paradigm is so different and so effective at a large problem domain (which includes mostly mathy things and big data), and you can do similar things in many languages, although not quite as elegantly and succinctly.

I faced two problems after K:

1. The whole software engineering world starts to look like a ridiculous house of cards; When you're used to seeing implementations of fast and efficient in memory databases in ~20 lines, or an npm-style package manger[1] in less than ~400 lines (comments included). Modern software engineering practices enable and encourage solutions that are inefficient in many respects. Maybe it cannot be better at a large enough scale, but it affects and infects the smaller scales as well. It is extremely frustrating.

2. Getting actual work done requires interfacing with the world, which isn't quite up to the k/q/apl standards of terseness and efficiency -- mostly "accidental complexity"[2]; So, e.g., if you have to have web presentation, or work on import/export, they dominate your effort due to accidental complexity that cannot be removed. Which is doubly frustrating.

[0] http://nsl.com/k/t.k

[1] https://github.com/yang-guo/qp

[2] https://www.quora.com/What-are-essential-and-accidental-comp...

APL/J/K are on their own league. I'm currently learning J, and the only language that has wowed me as much was Prolog and APL/J is even more profound. I won't say that I got ruined by Prolog, I got spoiled by it, but I carried over the good habits from it to other language. Sadly, I don't know that there's anything I can carry over from J. Perhaps it will improve and increase my ability to think of how to solve in parallel which is needed more and more with distributed computing/GPUs.

Conway's game of life in one line of APL: http://www.youtube.com/watch?gl=GB&hl=en-GB&v=a9xAKttWgP4&fm...

HN discussion(2010) : https://news.ycombinator.com/item?id=1041500

Those of you interested in APL/J/K might find Iverson's book Elementary Algebra interesting where he defines lots of operations in array notation. I dug up this PDF looking for one that was out of print:

http://www.softwarepreservation.org/projects/apl/Papers/Elem...

Texts of that era remind us of the brilliance of Knuth. http://en.wikipedia.org/wiki/TeX

oh wow, I have that book. I also have "calculus in a new key" and a few others. Yes, I was an APL child.

> what other programming language would have given you that luxury?

I'm not sure what you mean. C? C++? Java? Perl? Perhaps Python?

I think of those C and Perl fit the most.

You can't write C++ or Java like you did 20 years ago (of course, you could but you shouldn't). Both languages and their whole ecosystems have evolved tremendously in 2 decades.

The C and Perl style OTOH has changed less. A programmer of those language from 20 years ago that is transported to the present day will have much less problems fitting in than a programmer of C++ and Java would.

C++ and Java ecosystems were run over by people who read The GoF book and decided to generate every single permutation and combination of those patterns. Code largely comes out like AbstractFactoryServeletConfigurationSingletonDispatcher.

Also a lot of applications were written as huge monoliths even a few years back.

These days people write applications to do one task properly.

I was slightly surprised when I Googled AbstractFactoryServeletConfigurationSingletonDispatcher that your comment was the only match (at least at the time I looked).

That's possible. Last time I checked not everyone working in every single company uploads their code to some public website.

Also that word represents a culture which is what I was talking about.

My experience with C++ has been watching a trend towards standardization across platforms, and incorporation of functional programming concepts.

I've been writing C for 30 years+, and my style has changed massively in that time. In the meantime I did all kind of other things, perl, ruby, Obj-C, C++ (a LOT), java/script etc etc...

My 'design patterns' in C now has a lot more of the things I 'liked' about these languages, lots of abstractions, actors, compartmentalization and many many more, as well as the most important bits like multi-core/threads aware APIs and so on...

I think that if you stick not just to a language but to your set design patterns and even toolset, you fall into what I call 'mind sclerosis' -- HOWEVER -- it's not because your patterns evolve and you update your toolset that you need to change language and go with all the trends... Most 'modern' patterns can be done in any languages.

In fact I do a lot more C these days than I did for the last 20 years...

Perl style has changed over the years too. Current Perl coding standards and bulk of the code getting written is very different compared to the early internet Perl code.

> The C and Perl style OTOH has changed less. A programmer of those language from 20 years ago that is transported to the present day will have much less problems fitting in than a programmer of C++ and Java would.

This is categorically untrue for Perl.

Care to elaborate?

Well Perl 6 is pretty much a completely different language and it certainly didn't exist back then. I guess you could still be using Perl 5.x but iirc modern day projects use things like Moose which is relatively new too.

IME when talking about "Perl", most people consider that to be Perl5 and not Perl 6. Giving that Perl 6 can be and often is considered a different language.

But yeah, I agree with you about Moose. But I also stand by my opinion that Perl changed muss less than C++ or Java in that time period.

Compared to 98?

- DBIx::Class instead of DBI is a huge change; even DBI was reasonably new back then, with people still using MySQL.pm

- Moose and Moo over everything being hand-roled. I remember in 98 trying to convince people to use OO at all for anything.

- The testing ecosystem is very different / much improved, and people actually write them?

- People are really using strict, "use warnings" is a thing instead of -w

- Catalyst/Mojolicious/Dancer on Plack instead of mod_perl being cutting edge; even then, most stuff in '98 was CGI, with CGI.pm being luxury as opposed to people rolling parameter parsing by hand

- There were still many many many CPAN deniers in '98

- UTF8 and Unicode is actually a thing now, rather than an after-thought

etc

This depends on your target platform. Mine:

Haha. I know that many embedded programmers have to put up with gruesome outdated and awkwardly custom patched compilers, but yours takes the prize of the oldest.

I hope they pay you enough for the pain and suffering of using it. :-)

C++ was launched in 1985.

Perl was launched in 1987.

Python was launched in 1991.

Java and Javascript were launched in 1995.

C# was launched in 2000.

So the newest out of the popular languages is already 18 years old.

You don't need Fortran or Cobol or Lisp to have been able to do this... It's already almost 60 years since that time.

*how many languages would have given you [the luxury of programming effectively] for twenty years?

C++ doesn't qualify, to my mind, because the language has had many iterations and also because, as the post's author points out, writing C++ in the early 90s was not always a pleasant experience.

Python and even Perl are good contenders, as they have both been relatively stable languages. I'm not sure Java counts - Java 10 is quite different to Java 1.0, not just in terms of language features but often paradigms too (think 5's generics and 8's lambdas).

As for C# - I've never done .NET, so I'll have to take you on your word.

I know that Lisp has been largely stable, but are you sure it hasn't changed much? Programming paradigms advance, we didn't even have unit tests or continuous integration 20 years ago (at least not widely adopted in the industry). I find it hard to believe that even a Lisp programmer would be completely "static" across 20 years, i.e. the code written 20 years ago would be truly similar to the code he writes now.

So I'm not sure I buy this argument, unless someone has solid counter arguments.

I suppose I was thinking in terms of the OP's timeline - 1980-2000. I imagine the practice of writing Scheme code has changed a lot. Not to mention the number of teams migrating to Clojure.

I was paging through some old symbolics lisp machine code the other day and while I found some subtle differences in style, it was not so different from modern CL code. I think the differences that are to be found are less about the way one writes lisp and more that these days people make use of "standard" things like quicklisp, alexandria, fiveam, and other utility/portability libraries that didn't exist back then.

Edit:

I suppose a major change was that back then, CLOS was not yet part of the standard. There was a competing system being used at the time called flavors that had a lot of the same features. No one uses that anymore to my knowledge.

I think there was a big change in Common Lisp style in the late 2000s coming from Free Software, particularly concerning how macros and read macros were used. Edi Weitz's coding style had a big influence, and Tobias Rittweiler's named-readtables[1] was a paradigm shift. I think of Paul Graham's On Lisp[2] as the first wave of modern Lisp style, and Doug Hoyte's Let Over Lambda[3] as the second wave.

[1] https://common-lisp.net/project/named-readtables/ [2] http://www.paulgraham.com/onlisp.html [3] https://letoverlambda.com/

> I think of Paul Graham's On Lisp[2] as the first wave of modern Lisp style, and Doug Hoyte's Let Over Lambda[3] as the second wave.

Both are seen slightly controversial by some. On Lisp for example indicates that PG actually wanted to program in a different language - and eventually did: Arc.

not a general purpose language (but a DSL for relational data), but: SQL. :)

COBOL?

COBOL and luxury present in one English sentence is a syntax error.

If you never knew anything but COBOL you'd probably love programming it. Knowledge of better techniques can be seriously damaging to your career.

I suffered some damage from not wanting to touch Windows (3.1) after discovering Linux in the early 1990s. Today, most jobs advertisements still look toxic.

I can relate. At my workplace, I think I'm the only person on the whole site who uses Linux as their main OS in place of Windows. It has its obvious downsides, since company tools are designed to work on Windows and everything else is a bigger or smaller hack, but given my general comfort of working on top of Linux, I think I'm still better off feeling the pain of using a less supported but more comfortable OS.

As a Fortran and assembly language programmer, I developed a strong philosophical distaste of COBOL and the environment it thrived in. Then, my first consulting gig used RPG-III. Then, cobol was installed, and it was wonderful.

Per your own sentence, you've just committed a syntax error.

That's the problem with set of all sets, you never know when you commit hypocrisy. (;

Old timers being rained with hundreds of thousands each year to maintain legacy banking systems beg to differ

Just to clarify: that was a tongue in cheek comment. The cycle of language introduction, acceptance, toolchain maturity, obsolescence quickened up a LOT in the last 15-20 years. Many earlier languages, from ALGOL to Fortran would have given you a comfortably large set of jobs to choose from for over 20 years.

Perl?

Perl is one of those languages, if you get used to the power of Perl it could be really hard to move to other C based languages.

I can only imagine how it would be for anyone using Lisp. The power there is so much, going to something like Java from there would feel down right suffocating.

Going from Perl to Python in my case largely felt like trying to a run a marathon in chains.

I share your experience. Python took all the fun out of computing for me.

Your comment made me think of the quote by Guy Steele: "We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp."

Even the designers of Java didn't expect programmers to go from Lisp to Java.

> Going from Perl to Python in my case largely felt like trying to a run a marathon in chains.

I find that not surprising. Python is geared a specific type of programmers. If Perl fits your programming, you will feel constrained by Python.

Me personally, I never liked Perl that much. IMO it's not a programming language but a write-only brain dump.

But Ruby is to me what Perl is to others. It's combining the power and expressiveness of Perl with a consistent OO model like Smalltalk and with a sane syntax.

Ruby syntax is really quite insane. It's just that the insanity is contained in dark corners that most of us thankfully rarely have to deal with. Consider for example that this is the literal string "x": '% x '. So is % + linefeed + x + linefeed, because for most characters the character after a prefix '%' will be the quote character of a quoted string. And that includes whitespace.

There's all kinds of crazy little bits like that littered around Ruby.

It's still my favorite language, but it is also totally infuriating sometimes.

Indentation in itself never helps readability that much. Unless of course you are hiring programmers so bad, who can't do things as basic a thing as indenting code. And I seriously doubt such programmers will automatically transform to geniuses just by using Python.

Apart from that I haven't seen any thing in Python that makes code more readable.

Reply on news.ycombinator.com