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

341–350 of 379 posts

Re: In defense of complicated programming languages

#341

Post by pjmlp »

weavejester wrote: post #324
pjmlp wrote: post #294

Earlier quoted context omitted.

We can start discussing semantics then, when a language supports a feature, it is only when it is hardcoded on the compiler, or the language offers enough lego blocks to do it via a library.

It's when it's part of the core language, as any Turing complete language can implement any feature of any other Turing complete language. It's not a useful statement to say all languages support all features.

So I guess Common Lisp, Raket, Scheme, C++, C#, F#,... just lost a couple of features.

Re: In defense of complicated programming languages

#342

Post by pjmlp »

cttet wrote: post #336
pjmlp wrote: post #111

Earlier quoted context omitted.

One thing that is common to many people arguing is that they actually never bothered to read SIGPLAN, or CS type systems. So they argue with knowledge based on Internet facts instead of actual CS literature.

The natural language is evolved by people saying what they what and the majority became the language. Not defined by some elites or some authority. Classes binds data and functions together, and object systems supports inheritance. These are some of the things that some people don't really like, but you may not care. People sometimes care about syntax as well, writing "Class" is also part of the experience of using t…

Modules also bind data and functions together.

Not all object systems use inheritance, and even those that do, we can speak about delegation, interface/trait/protocols/type classes inheritance, regular classes inheritance, or some weird stuff like object patterns from BETA.

That is why we have CS literature, to put the right words in place.

Re: In defense of complicated programming languages

#343

Post by kazinator »

weavejester wrote: post #324
pjmlp wrote: post #294

Earlier quoted context omitted.

We can start discussing semantics then, when a language supports a feature, it is only when it is hardcoded on the compiler, or the language offers enough lego blocks to do it via a library.

It's when it's part of the core language, as any Turing complete language can implement any feature of any other Turing complete language. It's not a useful statement to say all languages support all features.

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 A instructions themselves. In that situation, UTM B itself has not acquired the features of UTM A.

Re: In defense of complicated programming languages

#344

Post by ncmncm »

lispm wrote: post #340
ncmncm wrote: post #330

Earlier quoted context omitted.

You have maybe noticed that Emacs is a single program? (OK, two or three, historically.) Emacs Lisp code that doesn't integrate with the rest of Emacs just doesn't work.

What I have noticed is that GNU Emacs is an application development platform for various programs. Example: Org mode. 133 k lines of Emacs Lisp code. https://orgmode.org Org mode then is also used by other tools. Somehow these 'Lisp macros' seem to integrate, even though they are written in different times (GNU Emacs started in the mid 80s) by many different authors, for different programs on top of GNU Emacs. That G…

I really don't care about Lisp.

The point is that if you are designing a language and want a lively ecosystem, you either build in features that establish conventions, or implement them in a Standard Library if the language is powerful enough to express them that way.

Failing to build common ground to enable libraries from different places to interact cleanly dooms your language to obscurity.

Re: In defense of complicated programming languages

#345

Post by donkeybeer »

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.

Sometimes textbook descriptions are just needlessly obtuse. I have noticed that there are some concepts which I already understood but if I were first introduced to them via the textbook, I would have been hopelessly confused. I wasn't confused only because I recognized this as something I already knew.

Re: In defense of complicated programming languages

#346

Post by renox »

WalterBright wrote: post #37

I remember first encountering classes. I simply could not understand what they were from reading the documentation. Later, I picked op Bjarne's C++ book, read it, and could not figure out what classes were, either. Finally, I obtained a copy of cfront, which translated C++ to C. I typed in some class code, compiled it, and looked at the emitted C code. There was the extra double-secret hidden 'this' parameter. Ding!…

I think like many programmers are "bottom up" (including me), I had a hard time understand virtual methods until I read an example on how they were implemented, then I was able to understand what it was and then the explanation why they were useful.

I remember two lessons about networks at school, the first one was "top to bottom" (layer 7 to layer 1), I understood nothing, then there was another one bottom up, and I finally understood networks..

Re: In defense of complicated programming languages

#347

Post by Zababa »

cttet wrote: post #337
Zababa wrote: post #80

Earlier quoted context omitted.

> If we use Clojure's philosophy of simple, Python is by no means a simple language, even without classes. There are a lot of special syntax like `with` `as` `elif` `for .. else` and concepts such as `nonlocal`, not even mention generators, decorators and lots of fancy stuffs, although it is easy to learn... Beware of the Turing tarpit where everything is simple but nothing is easy! Python is by no means perfect, but…

Yep, so as I said the definition of things like "simple", "complex" are super vague. | but using different syntax when doing different things can make a lot of sense. For C users yes, if we step back a little bit, for English users yes, but for people with other language background it may not hold. Every pieces of added syntax will utilise some human priors that may be specific to someone. But some really minimal sys…

My idea behind "make things that are different look different" doesn't come from language (at least not written language) but from visual media in general. For example, on a industrial machine or in a guide, people will often use lots of trick to distinguish some things from other. It isn't really syntax, but considering that programming is written text, we don't have much else than syntax to differentiate the parts on a quick read.

I think that may be a bias due to how I read code. I tend to skim it quickly at first, and then read the "more interesting parts" on a second pass. On the other hand, if you read code linearly, syntax may not be as needed. I'd like to see a study on eye movement when reading code and language preference, that may help reveal some patterns (or not.).

Re: In defense of complicated programming languages

#348

Post by lispm »

ncmncm wrote: post #344
lispm wrote: post #340

Earlier quoted context omitted.

What I have noticed is that GNU Emacs is an application development platform for various programs. Example: Org mode. 133 k lines of Emacs Lisp code. https://orgmode.org Org mode then is also used by other tools. Somehow these 'Lisp macros' seem to integrate, even though they are written in different times (GNU Emacs started in the mid 80s) by many different authors, for different programs on top of GNU Emacs. That G…

I really don't care about Lisp. The point is that if you are designing a language and want a lively ecosystem, you either build in features that establish conventions, or implement them in a Standard Library if the language is powerful enough to express them that way. Failing to build common ground to enable libraries from different places to interact cleanly dooms your language to obscurity.

Not sure what that has to do with Lisp then, since macros establish conventions, but on a language level.

Example: the Common Lisp Object System was initially developed as new a library, based on two other earlier libraries. This was then standardized and it is the standard way to develop object-oriented software in CL.

The library has three API layers: an object-oriented layer, a functional layer and a syntactic layer. The syntactic layer is implemented with Macros. It provides for the developer a convenient way to specify the elements of an object-oriented program: classes, generic functions, methods, control structures, ... As a developer everyone prefers to use the syntactic level.

There are many libraries and applications using it. It's also extensible, so that other user can add new behaviour to the object-system itself.

That macros enable new language extensions also on a syntactic level is nothing special. To use macros from other developers is not more difficult than using a class graph, or similar.

There is a lot of 'fear' of user-level syntax extensions from people who have never developed with it. Understanding the implementation of macros themselves is an added burden, since many developers are not used to write&read code which is written on a meta-level of incremental code generation. But there are practices which can be learned and applied. Macros themselves can make the code much more readable, since it allows one to support a problem domain also on a syntax level and hides implementation details.

Re: In defense of complicated programming languages

#349

Post by valenterry »

dwohnitmok wrote: post #287
dwohnitmok wrote: post #50

Earlier quoted context omitted.

> Haskell for example is not like that. Python does better here. I think Scala is one of the best languages in that regard. This seems ripe for getting a lot of passionate anecdotes out of the woodwork.

Ha or not. Looks like I was wrong.

Not enough attention maybe? :)

Also, I like Haskell. It's just that the learning curve is much steeper at the beginning. This also has an advantage in that you will rather find experienced people in a project and don't have to deal with different styles within a project. The drawback is that it's harder to learn while being productive at the same time.

Re: In defense of complicated programming languages

#350

Post by tialaramex »

Asooka wrote: post #238
tialaramex wrote: post #182

Earlier quoted context omitted.

Rust here says OK, we'll define Mul (the * operator) for the same type (and for references to that type) so let a: u16 = 0xFFFF; let b: u16 = a; let c: u16 = a * b; ... is going to overflow, Rust would actually detect that because 0xFFFF is a constant, so, this says "Silently do overflowing arithmetic" and er, no, it doesn't compile. However if you achieved the same thing via a blackbox or I/O Rust doesn't know at co…

I don't like Rust's approach, but it is better than C's. Rust should either commit to wraparound or make the default int type support arbitrary values. In C, the problem isn't the silent wraparound, the problem is that when the compiler sees that expression, it will assume that the resulting value is less than INT_MAX, and optimise accordingly. The other insidious problem is that wraparound is defined for other unsig…

I understand why you don't like C's behaviour here.

> Rust should either commit to wraparound or make the default int type support arbitrary values.

Committing to wrapping arithmetic everywhere just loses the ability to flag mistakes. Rust has today Wrapped and so on for people who know they want wrapped arithmetic. I'd guess there's a bunch of Wrapped out there, some Wrapped and maybe some Wrapped but I doubt any large types see much practical use, because programmers rarely actually want wrapping arithmetic.

The mistakes are real, they are why (thanks to whoever told me about this) C++ UBSAN in LLVM actually flags unsigned overflow even though that's not actually Undefined Behaviour. Because you almost certainly weren't expecting your "file offset" variable to wrap back to zero after adding to it.

For performance reasons your other preference isn't likely in Rust either. Type inference is not going to let you say "I don't care" and have BigNums in the same code where wrapping is most dangerous.

We can and should teach programmers to write checked arithmetic where that's what they meant, and Rust supports that approach much better than say C++. Also the most serious place people get tripped up is Wrangling Untrusted File Formats and you should use WUFFS to do that Safely.

Post reply on HN