4 ms·
You don't know what Scala code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. You don't know what Ruby c
by rst 16y ago
You don't know what Scala code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide.
You don't know what Ruby code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide.
You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide.
Heck, you don't know what annotated Java code is doing unless you're familiar with the build tooling that processes the annotations, and the libraries it invokes; syntax isn't much of a guide.
There's a pattern here. I'm not sure it has much to do with the language.
- fedd 16y ago> You don't know what C++ code is doing unless you're familiar with the specific libraries it invokes; syntax isn't much of a guide. i'd say this about Perl or Ruby, but C++?
- vilya 16y agoYeah. With operator overloading, automatic type conversions, template expansions and so on it's a fair criticism.
- stonemetal 16y agoC = A + B; In C++ what does this line do? The list of things that can effect what this line of code does are: Types of A,B, and C, single arg constructors, explicit conversion operators, operator +, operator =, and copy constructors might come into play. I more than likely have forgotten something from that list.
- VMG 16y agoMacros.
- beza1e1 16y agoThat's essentially the argumentation of Torvalds, why i likes C. In C you know, what the code does. Higher macro magic is rare.
- fogus 16y agoAnd his point (among other things) is that the lack of namespacing is a win in this respect because it fosters the practice of explicit naming like: `smtp_connect()` rather than `connect()`.
- Almaviva 16y agoThis is a silly excluded middle argument, no?
- jimbokun 16y agoLeft out Lisp macros.
- lyudmil 16y agoIsn't this to be expected when you add abstraction? I'll argue that not "knowing what [the] code is doing" isn't such a bad thing. In fact, I don't think we can have advances in language design without relaxing the constraint you're alluding to. Consider an extreme scenario where I've designed a language where the following line of code does what you'd expect: ask for an input, assume it is a number, calculate its factorial, and display it Notice that you have never seen this language before and you have no idea what's going on under the hood to make this happen. However, you know what the code is expected to accomplish. I think that's a worthwhile tradeoff. It's what all of these languages are trying to do - to allow the programmer to write down their thoughts as close to human language as possible. You only need to care about how things work at the lower level of abstraction when the abstraction has a bug or needs changing. If I can work 80% of my time at the level of abstraction of the "code sample" above (diving into the nasty internals 20% of the time) I'd start using that language immediately.