|
honey the codewitch wrote: You can produce more incomprehensible code with C++ than I think you can in any other major language
Hahahahaha ... not even close.
Work this out:
⎕←(~A∊A∘.×A)/A←1↓⍳N
or this:
life ← {⊃1 ⍵ ∨.∧ 3 4 = +/ +⌿ ¯1 0 1 ∘.⊖ ¯1 0 1 ⌽¨ ⊂⍵}
C++ can't even come close to APL for code density or incomprehensibility!
The first one is the Sieve of Eratosthenes, the second is the Game of Life.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Does anyone actually use APL anymore though? I mean significantly, not just people porting old code and the like? According to Wiki the last stable release was 21 years ago.
Real programmers use butterflies
|
|
|
|
|
Surprisingly, yes: Today, APL remains in use in a wide range of commercial and scientific applications, for example investment management,[82] asset management,[91] health care,[92] and DNA profiling,[93][94] and by hobbyists.[95]
I suspect APL programmers will tell you the last stable release was perfect, so it hasn't needed changing since ... they are generally an odd bunch, APL programmers ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Today, APL remains in use in a wide range of commercial and scientific applications, for example investment management,[82] asset management,[91] health care,[92] and DNA profiling,[93][94] and by hobbyists.[95]
So that's 4x no one can understand the ing stuff well enough to port ancient legacy code, and 1x s playing code golf.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
TECO was the same way. TECO was used to write the first version of Emacs and is a string processing language. One of the challenges TECO coders would do is write a one liner and challenge their counterparts to write the result of putting their name in the function.
|
|
|
|
|
I remember TECO - had a port of it as my first desktop computer editor!
Took some learning, but boy was it powerful when all you had was a line editor...
|
|
|
|
|
APL was my first language; in high school, then in university co-op work.
Yes, it's dense, and uses symbols you don't see on a regular kbd.
But it really changes how you think, for the good.
Functional programming (!)
Expressions on data collections, rather than rat-holing on iterators.
It was great for analytics of the first (StatsCan) time-series database.
After APL, I worked in C, ZOPL, PL/I, Algol, POP2, VB, perl, C++ and more
Every one added new bits for understanding the next one down the line;
some of them on what to avoid (I'm looking at you, C++20).
But APL was the strongest and cleanest.
Now JPMorgan uses it (well K),
because it is superfast for solving complex problems, and surprisingly straightforward.
Everyone has fun with the primes and GameOfLife oneliners )
They don't get to see the full applications. Sigh.
My2¢
|
|
|
|
|
mischasan wrote: because it is superfast for solving complex problems, and surprisingly straightforward.
Right up until someone asks for the studies that demonstrates those statements using something besides benchmarks (that are often coded well in one language and then so poorly done in other languages that one suspects that they were written that way deliberately.)
But to be fair I am certain I have seen that claim about every language and based, when based on anything at all, on the same sort of lopsided benchmarks.
|
|
|
|
|
"Superfast for solving problems" -- superfast for the solver to formulate. Sorry if that it sounds like, "superfast execution time".
Building systems in APL for Rank Xerox, I sometimes completed and ran a solution in the course of a short conversation; so we could get on with the conclusion from its result. Occasionally (rarely) was its speed of execution an issue.
|
|
|
|
|
If you've got a system that supports dc, try this:
dc -e '2p3p[dl!d2+s!%0=@l!l^!<#]s#[s/0ds^]s@[p]s&[ddvs^3s!l#x0<&2+l.x]ds.x'
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
How long do I need to wait for it to finish?
|
|
|
|
|
It will stop when it has guessed your password and emailed it.
[I have no idea what it does]
|
|
|
|
|
Well, after about 24 hours on an ancient and very slow laptop, it hit this milestone:
99999847
99999931
99999941
99999959
99999971
99999989
100000007
100000037
100000039
100000049
100000073
100000081
100000123
100000127
100000193
100000213
100000217
100000223 I took pity on the poor beast shortly afterwards.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
|
|
|
|
|
|
I don't have a problem converting C to C++ except when it comes to interrupt handlers, they're a bit tricky.
But then again I'm not converting very complicated code...AVR devices are pretty simple.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
The Eureka moment with C++ is when you understand what features you really don't want to use because they make the code less comprehensible. like multiple inheritance from multiple classes with a common base class.
That being said, I once wrote a co-operative multitasking OS for an embedded system in less than 15K of binary in Turbo C++. All the task and timer lists were automatically set up by the class initializers at startup. Just link it in and it got scheduled.
"Time flies like an arrow. Fruit flies like a banana."
|
|
|
|
|
My issue comes largely from my finicky-ness. I do a lot of C++ programming, and while I hesitate to say I'm proficient at C++, on balance I'd be lying if I said I didn't think I was.
What I mean by being picky is that I don't keep C-isms in my C++ code. I port macros to ifs on constexpr values, and I use templates a lot, like for pin assignments in this case, but it means restructuring code, which means understanding it.
Real programmers use butterflies
|
|
|
|
|
C++ is my favorite language because it does not force you to do anything. That does include making it readable, which is the original author's fault not the language. Languages that force you to make your code readable will inevitably loose some (potentially very useful) features in order to make that happen, like #define for example.
I admit I am guilty of intentionally making code less readable, only because I am forced to run it through a painfully awful "security" code scanner. The program is a web api in c# and the only way we can take any kind of data from the db and return it to the caller without the scanner whining is to store the data in a dictionary (dynamic) and then retrieve it back again, so that's been wrapped up in a pair of methods: return obfuscator.get<typenamehere>(obfuscator.insert(db.runProc("ProcName", args, or, whatever)))
|
|
|
|
|
I agree with you. I would say my complaint - if anything - I mean, I LOVE C++, is that it makes it easy to do The Wrong Thing(TM), and that includes hiding intent. Showing intent is everything, particularly in C++ where there are a billion ways to skin a million cats. However, that takes practice, is not always possible without comments, and is easy to ignore if you get lazy.
Real programmers use butterflies
|
|
|
|
|
I would say that the PEEK s and POKE s, segmented memory addressing, and goto s in my youthful program studies, were more intent-hiding than almost any of the C++ code I've seen since then! Some early Basic programs had me head scratching a lot!
|
|
|
|
|
#ifndef SCANNER_LIVE
doInjection(args);
#endif
|
|
|
|
|
Unfortunately the scanner isn't intelligent enough to know what ifdef means. We just took all the unit tests out of the repo because it was complaining about using assert, among other things. So now jenkins has to pull 2 repos to run the tests.
|
|
|
|
|
Memtha wrote: only because I am forced to run it through a painfully awful "security" code scanner.
...and because you are working for a company that doesn't know what they are doing. Or perhaps an individual up the authority chain that doesn't.
|
|
|
|
|
working for a company that doesn't know what they are doing
Close. The company is very good, but the client is... government. Need I say more?
Some battles just aren't worth the effort. We had to teach the "security lead" how to use git to get the zip and upload it to the scanning service they have forced on us. It's not even the government personnel that chose the scanner, it's a rival contractor that loves to tout the sheer number of "vulnerabilities" that "they" "addressed" by forcing us to add try/catch/throw on every single method.
|
|
|
|
|
Memtha wrote: but the client is... government. Need I say more?
lol - nope.
|
|
|
|