Interesting discussions since I last checked this thread.
So apparently vim is the Dwarf Fortress of text editors. Is this thing worth learning, or does anybody have a suggestion for a lightweight coding-focused text editor on linux?
The main reason to learn Vim is for shelling into a remote system. Once you've made that choice, it's a very powerful, very customizable editor suitable for almost any programming language. (Java being the main exception. A good auto-completing IDE is almost a requirement for overcoming Java's deficiencies as a language.)
If you don't expect to be dealing with servers, though, the learning curve may be steeper than you want to tackle. Yes, it's about on par with Dwarf Fortress, except that you don't even have a list of valid keys on the side of the screen. On the other hand, there are helpful patterns in the command structure, many of them enter muscle memory over time, and you get to define your own.
As far as something more lightweight, my co-workers have been transitioning from
Sublime Text to
Atom. It even seems to have a Vim mode plugin, so I might get around to trying it.
Looked at that site, stumbled over Perl 6, looked it up, and holy shit it's powerful. Perl 5 is already very powerful and concise, but Perl 6 takes the cake and also every other confectionery, and they're still not done adding features after 15 years of development.
So I've been using Perl 5 extensively and reading Perl 5 books for ten years now, and I'm now an expert on all things Perl 5 (of which there are lots). This includes being able to read Perl 5 well, because apparently Perl 5 is hard to read for people who haven't done a lot of it. But Perl 6, that's a whole new shipment of alphabet soup. Perl 6 has every single feature you could possibly imagine in a programming language, and if it doesn't have a feature, then it has a feature to let you add that feature in three lines of code or fewer.
Perl 5 is hard to read and write if you haven't done a lot of it
in the last six months. After switching to Python, because I was so much more productive with it, I have occasionally wanted to write a Perl script because it was the right tool for the job, and keep getting tripped up over the right way to index a hash, among other things. That last big program I wrote, that became so much more after rewriting it in a sane language? I can't quite follow the logic flow anymore, and no longer have a system that runs it correctly.
The reason I liked it in Python is that it wouldn't flip a shit when trying to concatenate strings with various other things. And when using a strong-typed language, "forgot the type declaration" is usually the first stupid mistake I make.
This is one reason to perhaps learn a typed language before learning a non-typed language. Like learning to drive a manual before an automatic.
I sometimes accidentally write "for(int i=0; i< n; i++)" in Javascript because I'm so used to putting the type in, rather than your problem.
"The interpreter does everything for you" is both a blessing and a curse for learning to program.
The same can be said of "The compiler does everything for you." When first learning to program, having the compiler take forever to spit out a lengthy list of massively confusing garbage because you forgot a semicolon is highly frustrating; then, when it actually compiles, it's far too easy to think that it's done even though your logic is terribly flawed in some nearly invisible way. Languages that let you poke around with a REPL are much more helpful in some respects, and Python's help() function is often exactly what I need.
Then again, I wouldn't mind a statically typed language so much if it inferred the type from initialization and/or usage, and didn't take a noticable time to compile. Unfortunately, those goals may not be compatible.
In other words, I really hate makefiles. The C and C++ compilation process is just complicated if your IDE doesn't manage the makefiles for you. VS is fantastic. Using a raw text editor or minimal IDE is not, and I don't know of any good fully integrated IDEs for Linux that work well with C++. My experience with Eclipse doesn't lead me to believe that it works well with C++.
It took me a good hour to realize that I'd modified a header file and added some properties to one of the structs, but because of the simplistic makefile I was using that didn't trigger all of the modules that included it to be rebuilt. Some did, some didn't. Fun ensued.
I've had good experience with hand-built makefiles for small projects, but the auto-generated ones used by most projects seem excessively inefficient and sometimes just wrong. Then again, getting dependency file generation to work correctly is its own nightmare.
One of the main reasons I prefer Python over C/C++ is its sane module system. When you import a module, you get that module as it is, not as it was the last time you compiled the importing module. You can try to import a module whether it exists or not; if it doesn't, you can even detect that condition at runtime and switch to a fallback. Importing a module automatically compiles it if necessary. You can also import individual names from a module, with the same behavior. And "global" variables live in their module's namespace, so they can be read or manipulated by other modules, but not accidentally.
Yes, all of that could be done in a statically-compiled language. Header files are simply bad design.
enforcing Get and Set operators also prevents one of the most common bugs:
if(object.value = true)
do_thing();
where you accidentally put a single-equals. Using a Get/Set paradigm would give a compiler error here, thus avoiding shipping with the bug. Writing Get/Set operators is pretty quick. Tracking down such a bug in 1000's of lines of code can take a while.
I once used a language where the single-equals operator was assignment at the statement level, but comparison within an expression. It also had double-equals (
==) and colon-equals (
:=) operators for disambiguation, but the simple case was almost always correct. Why don't more languages do that?
There's also optimization. Say you have a bunch of bools. You make Get/Set operators for each bool. Next, you want to optimize memory use, so you want to pack all the bools into bits in one internal int. If you wrote Get and Set operators for the bools, you can modify those functions to do your fancy bit packing for you. If you were directly editing a bool, you'd have to modify the client code in many files to change this internal storage behaviour.
This is where the property syntax of more modern languages is useful. A simple instance variable can be changed into a property without modifying client code, but calling getter and setter methods invisibly. (Granted, this re-enables the accidental assignment bug...)
What really baffles me is when a programmer creates public property-type getter and setter methods that do nothing but get and set a private instance variable with a nearly identical name. That's exactly like having a public variable, but more verbose and slightly slower. Yet some programmers do it by default...
Is there even any Flash in common use, besides sites that specifically gather unique Flash content (Newgrounds, Kongregate, boorus, etc.)? I didn't like Youtube's HTML5 player at first, but now I'd never go back to the flash player.
At my previous job, we used it to let the users record audio. I'm pretty sure they still use it, considering that some of their clients are over a decade behind in browser installations, and HTML media capture still isn't widely implemented.
I dunno, that'd convince me to take a moment and learn DVORAK.
Me too. Carpal tunnel is basically Hitler.
Sadly, Vim is the main reason I stopped using Dvorak. Muscle memory was already too strong, and the standard movement keys were scattered all over the place.
To stave off carpal tunnel, I use an
AlphaGrip. It's not perfect, and takes quite a bit of time to get used to, but it's generally more comfortable.
The problem is a thing call logic flow. Flow starts at the top and goes to the bottom, taking into account loops etc. Any equation you use is computed at the location in the code where it appears.
so if you have (just pesudocode):
x = 1
y = 2
f = function(x,y)
cin << x
print f
Then 'f' will have been computed as function(1, 2) regardless of what x value the user inputs, because that happens after the f-value is calcuated.
Think of it like a cake recipe more than maths. i.e. the function would be equivalent to "mix the eggs and milk together", and the cin would be like "decide how many eggs to use". Putting "decide how many eggs to use" after the mixing step would be a clear error.
I like the recipe analogy. It reminds me of something I heard once, about programming being the art of breaking something down into instructions so simple that a dumb computer can follow them.
But yes, the disconnect here is the difference between declarative ("Define
f as the result of applying
function to
x and
y") and imperative ("Apply
function to the current contents of
x and
y, and store the result in
f") languages. Math is almost always declarative, where programming is usually imperative.