Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of complicated programming languages

viralinstruction.com

Post reply on HN
Print view View original

361–370 of 379 posts

Re: In defense of complicated programming languages

#361

Post by IshKebab »

pritambaral wrote: post #171
IshKebab wrote: post #154

Earlier quoted context omitted.

Pythagorus's theorem is literally written using algebra. You can't even write it down without algebra.

algebraic notation != algebra It can totally be written without "algebra"; it's not the notation that contains the idea, it's only the idea that happens to be often expressed in this notation. I could use any other notation, or even plain English, to express the idea, if I didn't mind the extra verbosity. For Example: 1. The Berlin Papyrus 6619 (from 2000-1786 BC Egypt) uses prose [1] 2. The Ancient Chinese mathemati…

> algebraic notation != algebra

Ha where did you get that crazy idea?

> The Berlin Papyrus 6619 (from 2000-1786 BC Egypt) uses prose

Just because it's prose doesn't mean it isn't algebra. For example "If you square the lengths of the two shorter sides together and add them up it equals the length of the square of the length of the longer side". That's just algebra with words.

The thing that makes algebra algebra is that you use variables, not constants. "the length of the longer side" is just a wordy variable.

Re: In defense of complicated programming languages

#362

Post by IshKebab »

alecst wrote: post #169
IshKebab wrote: post #74

Earlier quoted context omitted.

Static types are definitely make the language more complicated. It will have a bigger specification and more complicated implementation. You could even argue it makes writing programs more complicated. But they definitely also make writing programs much much easier. Kind of like how algebra is more complicated than basic arithmetic, but good luck proving Pythagoras's theorem without algebra.

Google Einstein’s proof of the Pythagorean theorem. I’ve won quite a few bets with it. :-)

I did and they were full of algebra. Anyway as I've said elsewhere Pythagorus's theorem is an algebraic formula, so you can't even state it without using algebra.

Converting the equation to prose doesn't mean it isn't an algebra anymore. The key feature of algebra is manipulation of variables.

Re: In defense of complicated programming languages

#363

Post by kazinator »

weavejester wrote: post #355
kazinator wrote: post #343

Earlier quoted context omitted.

Rather, any Universal Turing Machine can be programmed to calculate whatever any other Universal Turing Machine can be programmed to calculate. It's not necessarily done with the same features, or use of resources. In some cases, the only way the features of some UTM A's architecture will be obtained through UTM B, is if UTM B is used to create a simulation of UTM A, and so then that provides a way to execute the UTM…

There are two problems with making that distinction. First, by that definition, few languages have regular expressions as a feature. Second, in languages with support for syntax rewriting, that would mean the internal implementation, not the user-facing syntax, is what decides what counts as a "real" feature.

A TM is a machine which accepts a tape, together with a specific tape: it performs a very specific calculation.

A UTM can take an instructional input which turns it into a different machine, which can then process tapes designed for a different TM mechanism.

A fixed programming language (and its standard library) is a UTM. If there are regular expressions in the language syntax, or the library, it's a feature of the UTM.

Everything else is instructions: additional libraries, macros, whatever.

We can extend languages by pretending that the additional code we have written (libraries, syntax rewriting) comprise a new, extended language. So that's a new UTM.

There are limits in what syntactic rewriting can provide in a seamless, efficient way. Some features are simply not expressible in the target language of the rewriting, other than by using the syntax to create an inefficient, interpreted language. The use of the features it provides is walled off within the embedded syntax. (Not to deny that this is nevertheless valid and practically useful.)

The UTM theory tells us that we can always adapt a UTM to accept the tapes intended for any TM mechanism. However, it doesn't tell us how costly that is. For some TM mechanisms, the approach may be to translate a given tape up-front into the UTM's own instructions and then run it directly. For some TM mechanisms, the approach may be to simulate the mechanism: the UTM's instructions execute the simulator, which executes the tape. The UTM theory mostly talks about simulation.

What we know is given a Turing Complete language A (i.e. a UTM) we can always write an interpreter for language B. That's the baseline. We then have a new UTM equivalent to B, consisting of language A, plus the interpreter. That setup then accepts programs of language B, and their inputs.

Re: In defense of complicated programming languages

#364

Post by CRConrad »

WalterBright wrote: post #301
LEDThereBeLight wrote: post #90

Earlier quoted context omitted.

I understand this thought process, but in my opinion it's the wrong way to think about software concepts. Understanding what a bridge is doesn't mean knowing how to build one, and in fact tying your understanding to a certain implementation of a bridge just limits your ideas about what is, in fact, an abstract concept. We understood functions as "mappings" between objects for hundreds of years, and when programming c…

Chris, a friend of mine in college (who is unbelievably smart) decided one day to learn how to program. He read the FORTRAN-10 reference manual front to back, then wrote his first FORTRAN program. It ran correctly (as I said, the man is very smart) but ran unbelievably slowly. Mystified, he asked another friend (Shal) to examine his code and tell him what he did wrong. Shal was amazed that his program worked the firs…

> This is why understanding only the abstractions does not work.

I don't think your example shows that at all: If it didn't actually explicitly say in his Fortran reference manual that "The 'thing' you write between a file-open and a file-close can only be a single character", then... Sorry, but then AFAICS your example only shows that he didn't understand the abstraction that "file-open" just opens a file for writing, without specifying what to write. (Maybe he slavishly followed some example in the manual that only wrote one character?)

This needless sprinkling of file-open / file-close looks a bit like he did the work of a current optimising compiler (only here it was pessimising), "unrolled a loop"... So AIUI it shows the opposite of what you set out to show: Too concrete without higher-level understanding was what did him in.

Re: In defense of complicated programming languages

#365

Post by CRConrad »

WalterBright wrote: post #299
dogleash wrote: post #196

Earlier quoted context omitted.

>There's a reason why computer science professors explain concepts at a high or abstract level and don't jump into implementation to help students understand them. It's because they're trying to teach something to people who don't have anything to build on. Later in their education that'll be different. At the school I attended Object Oriented Programming class had Computer Organization as a pre-req and the teacher w…

I did not understand what virtual functions were at all until I examined the output of cfront. Oh, it's just a table of function pointers.

You must have just had the bad luck to have read the most appallingly stupid books. I think you might be even a little older than I, and I got into the game late-ish; those C++ manuals or specs you read were probably from the 1970s or 80s? By the time I learned (imperative- and inheritance-based[1]) OOP from the Delphi manuals in the late nineties the virtual method table was explicitly mentioned and explained, along with stuff like "since all objects are allocated on the heap, all object references are implicitly pointers; therefore, Borland Object Pascal syntax omits the pointer dereferencing markers on object variable names" (which you also mention about C above). I'm fairly certain this gave the reader a pretty good grasp of how objects work in Delphi, but I still know nothing about what machine language the compiler generates for them.

It's not the idea of top-down learning from abstractions that's wrong, it's being given a shitty presentation -- more of an obfuscation, it seems -- to learn about the abstractions from that is the problem.

___

[1]: So yeah, that whole Smalltalk-ish "messaging paradigm" still feels like mumbo-jumbo to me... Perhaps because it's even older than C++, so there never were any sensible Borland manuals for it.

Re: In defense of complicated programming languages

#366

Post by CRConrad »

anonair wrote: post #295
marcosdumay wrote: post #207

Earlier quoted context omitted.

Yes, you are correct. But you are wrong too. People need complete understanding of their tools. And complete understanding includes both how to use the concepts they represent and how those concepts map into real world objects. If you don't know both of those, you will be caught by surprise in a situation where you can't understand what is happening. That focus on the high level only is the reason we had a generation…

IMO this is very elitist view of software developers' job. The analogy from tangible world would be all the bridge engineers using "proven" / "boring" / "regulator endorsed" practices and techniques to build a "standard" bridge versus those constantly pushing the limits of materials and construction machines to build another World-Wonder-Bridge. There is nothing wrong with having both types of engineers.

> There is nothing wrong with having both types of engineers.

Acksherly, yes there is. In this context, there is: The world doesn't need engineers "constantly pushing the limits of materials" when building bridges; let's stick with proven, boring, regulator endorsed practices and techniques for that.

Re: In defense of complicated programming languages

#367

Post by CRConrad »

skohan wrote: post #320
AnimalMuppet wrote: post #277

Earlier quoted context omitted.

I would disagree with where you are drawing that line. I would say that computer science does happen in Plato's heaven; software engineering happens in real processors and memory. But most of us are actually software engineers (writing programs to do something) rather than computer scientists (writing programs to learn or teach something).

I agree that there is some value to purely theoretical work, but I think this is over-valued in CS. For instance, in the first year of physics instruction at university, problems are often stated in the form of: "In a frictionless environment..." I think a lot of problems are created in the application of computer science because we treat reality as if there are no physical constraints - because often it is the case…

> I think a lot of problems are created in the application of computer science because we treat reality as if there are no physical constraints - because often it is the case that our computers are powerful enough that we can safely ignore constraints - but in aggregate this approach leads to a lot of waste that we feel in every day life.

ObTangent: Bitcoin.

Re: In defense of complicated programming languages

#368

Post by CRConrad »

versteegen wrote: post #191
sanxiyn wrote: post #46

Earlier quoted context omitted.

You've never seen tutorials written that way because roughly nobody but you learns programming languages from the bottom up. There is just no demand. By the way, where can I read a D tutorial from the bottom up?

The last time I learned a new programming language (Squirrel), I did so by reading the VM and compiler source code in detail rather than writing code. You get a far more complete picture of the semantics that way! I didn't even read much of the documentation first; it answered far too few of my questions. (Edit:) I want to know things such as: how much overhead do function calls have, what's the in-memory size of var…

> I want to know things such as: how much overhead do function calls have, what's the in-memory size of various data types, which strings are interned, can I switch coroutines from inside a C function called from Squirrel...

So is that a problem with learning from abstractions, or just simply a problem that this stuff isn't mentioned in the manual?

Re: In defense of complicated programming languages

#369

Post by [deleted] »

CRConrad wrote: post #367
skohan wrote: post #320

Earlier quoted context omitted.

I agree that there is some value to purely theoretical work, but I think this is over-valued in CS. For instance, in the first year of physics instruction at university, problems are often stated in the form of: "In a frictionless environment..." I think a lot of problems are created in the application of computer science because we treat reality as if there are no physical constraints - because often it is the case…

> I think a lot of problems are created in the application of computer science because we treat reality as if there are no physical constraints - because often it is the case that our computers are powerful enough that we can safely ignore constraints - but in aggregate this approach leads to a lot of waste that we feel in every day life. ObTangent: Bitcoin.

[deleted]

Re: In defense of complicated programming languages

#370

Post by weavejester »

kazinator wrote: post #363
weavejester wrote: post #355

Earlier quoted context omitted.

There are two problems with making that distinction. First, by that definition, few languages have regular expressions as a feature. Second, in languages with support for syntax rewriting, that would mean the internal implementation, not the user-facing syntax, is what decides what counts as a "real" feature.

A TM is a machine which accepts a tape, together with a specific tape: it performs a very specific calculation. A UTM can take an instructional input which turns it into a different machine, which can then process tapes designed for a different TM mechanism. A fixed programming language (and its standard library) is a UTM. If there are regular expressions in the language syntax, or the library, it's a feature of the…

> If there are regular expressions in the language syntax, or the library, it's a feature of the UTM.

By "the library" do you mean the core library of the language?

If a language didn't have regular expressions as part of its core library, does that mean regular expressions would not be a feature of that language?

> Some features are simply not expressible in the target language of the rewriting, other than by using the syntax to create an inefficient, interpreted language.

Why inefficient? Why interpreted? What if the syntax was efficiently compiled?

Post reply on HN