3 ms·

I'm learning Scala now and am impressed by its difficulty. Not since I learned C++ in college have I needed to spend the same amount of time and effort learnin

by dkarl 16y ago

I'm learning Scala now and am impressed by its difficulty. Not since I learned C++ in college have I needed to spend the same amount of time and effort learning a language, and the arguments given here against Scala are exactly the arguments you hear against C++. That's heartening to me. C++ is a great language for people who 1) know the language, and 2) use it sensibly (which often means humbly.) There's all kinds of stuff you can do with C++, including metaprogramming magic that gives you DSL-like capabilities a la Boost Spirit. I can't imagine using Boost Spirit in production code myself. Maybe there's a good use for it somewhere -- probably so -- but I really don't care if Boost Spirit is every a good idea anywhere. Maybe it's just an abomination; I don't care! All I care about is that I can make a good judgment about allowing it into my codebase. I'm going to approach Scala with the same attitude.

Stormbringer 16y ago
One of my CS professors made the remark that C++ seemed like it had been designed by people who thought that there was a tax on keyboard symbols. So rather than using new symbols that were on a standard keyboard but not part of the language already, they just reused the old symbols either as is or in strange new combinations. When I look at Scala it gives me that same feeling. Additionally, they seem to come from the 'god kills a kitten every time I press a key' school of thought so everything looks really compressed and cramped. Granted it's not as bad as Perl or something you might see in an obfuscated C contest, but it seems a step away from Java in terms of readability. Which seems a shame to me. It is as though they said to themselves, "we will increase the utility, but something must be sacrificed". I just kind of wish they had added the extra power, but not at the expense of making it harder to read.
- dkarl 16y ago
  I don't see any symbols on my keyboard that weren't already used in C except @ and ` (backtick.) P.S. I forgot about $.
  - Stormbringer 16y ago
    Let's assume you're right. You also need to consider the composite symbols. Example: >> already has a meaning in C++ so instead of reusing the exact same combination why not invent a new symbol (made up of two or more symbols) for sending Strings to the output? E.g. I don't know, something that looks a bit more like the terminal prompt ?> or $> or even go wild and crazy $$ If you say "lol u nuub, operater overloading!" then I would reply if operator overloading is good, then having more operators defined at the language level and thus available for overloading is better, yes?
    - scott_s 16y ago
      The operators >> and << don't mean "send strings to output," they are stream operators that either put something into a stream (<<) or take something out of a stream (>>). They're actually a surprisingly intuitive notation because the arrows point in the direction of data movement (since the stream is always to the left). There aren't many other notations that can be as intuitive and bidirectional. The next obvious notation, -> and <-, are off limits because -> is already a legal operator on an object. There are many valid criticisms of C++. I don't think not using enough keys on the keyboard is one of them.
scott_s 16y ago
I used Boost Spirit in my dissertation project for the parsing: https://github.com/scotts/cellgen/blob/master/src/cellgen_grammar.cpp#L289 https://github.com/scotts/cellgen/blob/master/src/cellgen_gr... I would not choose it again. With what I wanted to do, the performance was poor. Spirit just had to deep-copy the parse tree it was generating way too much. I liked having all of my source in C++, which meant not having to embed C++ in ANTLR or yacc. But I'm not sure that was worth it. Perhaps the newer version fixes that problem, but I doubt I'll ever test it out for sure. Luckily for me, the performance of the compiler itself was not really a priority. And it was a research project, so it didn't really matter. Anyway, I know your point was broader than Spirit specifically, but I thought you may be interested in my experiences.
- munificent 16y ago
  Is there a reason you didn't just handcode a recursive descent parser?
  - scott_s 16y ago
    Yes. It's a waste of time. Why should I hand-code a parser for C when it's a solved problem? Note that the source code I linked to calls into an already existing Spirit grammar for C (which I made some modifications to, mainly so I could get more information back from the parse tree). Hand coding a parser is generally not a good use of your time. There are many tools available to generate a parser based on a BNF grammar. I used my project as an opportunity to learn one of them.

by dkarl 16y ago

Stormbringer 16y ago

One of my CS professors made the remark that C++ seemed like it had been designed by people who thought that there was a tax on keyboard symbols. So rather than using new symbols that were on a standard keyboard but not part of the language already, they just reused the old symbols either as is or in strange new combinations. When I look at Scala it gives me that same feeling. Additionally, they seem to come from the 'god kills a kitten every time I press a key' school of thought so everything looks really compressed and cramped. Granted it's not as bad as Perl or something you might see in an obfuscated C contest, but it seems a step away from Java in terms of readability. Which seems a shame to me. It is as though they said to themselves, "we will increase the utility, but something must be sacrificed". I just kind of wish they had added the extra power, but not at the expense of making it harder to read.

dkarl 16y ago
I don't see any symbols on my keyboard that weren't already used in C except @ and ` (backtick.) P.S. I forgot about $.
- Stormbringer 16y ago
  Let's assume you're right. You also need to consider the composite symbols. Example: >> already has a meaning in C++ so instead of reusing the exact same combination why not invent a new symbol (made up of two or more symbols) for sending Strings to the output? E.g. I don't know, something that looks a bit more like the terminal prompt ?> or $> or even go wild and crazy $$ If you say "lol u nuub, operater overloading!" then I would reply if operator overloading is good, then having more operators defined at the language level and thus available for overloading is better, yes?
  - scott_s 16y ago
    The operators >> and << don't mean "send strings to output," they are stream operators that either put something into a stream (<<) or take something out of a stream (>>). They're actually a surprisingly intuitive notation because the arrows point in the direction of data movement (since the stream is always to the left). There aren't many other notations that can be as intuitive and bidirectional. The next obvious notation, -> and <-, are off limits because -> is already a legal operator on an object. There are many valid criticisms of C++. I don't think not using enough keys on the keyboard is one of them.

scott_s 16y ago

I used Boost Spirit in my dissertation project for the parsing: https://github.com/scotts/cellgen/blob/master/src/cellgen_grammar.cpp#L289 https://github.com/scotts/cellgen/blob/master/src/cellgen_gr... I would not choose it again. With what I wanted to do, the performance was poor. Spirit just had to deep-copy the parse tree it was generating way too much. I liked having all of my source in C++, which meant not having to embed C++ in ANTLR or yacc. But I'm not sure that was worth it. Perhaps the newer version fixes that problem, but I doubt I'll ever test it out for sure. Luckily for me, the performance of the compiler itself was not really a priority. And it was a research project, so it didn't really matter. Anyway, I know your point was broader than Spirit specifically, but I thought you may be interested in my experiences.

munificent 16y ago
Is there a reason you didn't just handcode a recursive descent parser?
- scott_s 16y ago
  Yes. It's a waste of time. Why should I hand-code a parser for C when it's a solved problem? Note that the source code I linked to calls into an already existing Spirit grammar for C (which I made some modifications to, mainly so I could get more information back from the parse tree). Hand coding a parser is generally not a good use of your time. There are many tools available to generate a parser based on a BNF grammar. I used my project as an opportunity to learn one of them.