[split] Lines of Code

[SMcNeill]

Oh man! I did not see the 10:09 PM EDIT of Steve's crazy long one-liner employing some interesting tools!
+1 It's ugly long but I like it!
I can't imagine a coder who doesn't find this stuff interesting.

Who cares what the code looks like as long as it does it's job?

Maybe those who think code writing could be an art.

It's not really the type of code that people should be studying for any sort of 'real world application' though.  It's good for a thought experiment, and a 'is it possible' type thing, but absolute nuts in a "Should I use this method" perspective.  Like I mentioned -- it's twisting the commands with "obscure and inane ways to generate logic".

One line which...

Shells to the console.
passes a batch command -- a very ugly, multiline batch command joined by & linkers which are the equivalent of colons in BASIC
that batch command makes a variable
asked the user to input a value into that variable
returns the value to the clipboard for later use
returns to the program
Which then checks to make certain a value was given and if that clipboard value was less than 0 or not.
If the value is less than 0, the _IIF will return the inches conversion from the clipboard value copied
If the value is not less than 0, the )IIF will return the negative millimeters conversion from the clipboard value copied.

.
.
.

It's a completely insane way to do things.

Does it generate the shortest line count and user input? Sure, it does!

Is it something that should ever actually be done in programming? Nope! It's crazy and prone to break on a zillion points in the future, if the OS changes the Terminal or the Console, or if the user is stuff with the clipboard, or a zillion other things that could screw up that interaction.

It's a good thought exercise, and *technically* it works. Practically though, it's not the type of thing that one would ever see or use outside of thought exercises.

---

A similar example would be in engineering: Ask any engineer how to make a 1970 Volkswagon go 200 miles per hour without some form of rocket or major alteration done to the vehicle.

One smart arse is going to speak up and say, "Push it off the top of the Grand Canyon and set the radar gun before it hits the ground."

*Technically*, they'd be right and it'd be a working solution. Practically however, it's not something that you'd ever really want to implement for any real use case in the real world.

---

It's good for trying to think outside of the box and pushing what CAN be done, or trying to just challenge one's perspective on things. I just don't think it's something that one needs to push so heavily on someone just starting the language and on Lesson Two of the tutorial.

One doesn't talk advanced philosophy in a classroom where the students are just learning to speak the language.

And that's not to say that it's wrong to speak philosophy. It's just one should think about the time and place, and perhaps move such in depth and complex subjects somewhere a little more refined so as to not discourage the newcomers as they struggle with the basics.

---

I do get a feeling of defensiveness.

Apologies, if you feel like I'm attacking you or anything. That's not my intent at all.

Personally, I *like* the mental thought challenge of trying to reduce the number of lines in a set of code. It's something that I feel more of the *advanced* coders should do from time to time, as it encourages one to look at the tools in their programming set and see if they're the proper ones for the job, or if they can be used more efficiently.

My only concern is with someone picking up the language thinking that it's okay to write such junk as I did, just to keep line count down. Beginners should focus on simply *writing code that works*, first and foremost. Once they've learned the different keywords, and learned how to put them together and make things flow and work properly, THEN they can start to think about things like, "Would DO be better here, or FOR? Can I rearrange this logic to improve performance? Can I shorten this workflow to something simpler?"

Thing is, they have to know how to make it work first, before bothering to worry about how to make it work with the least amount of code.

And that's why I want to stress that obsession over lines of code isn't something that most folks need to worry about. It's not that I'm speaking to YOU in particular; you've mastered the language enough to appreciate the nuances and enjoy looking at the obscure and unusual ways to do things. I just don't want everyone else (particularly those just learning the language) to think that it's something which THEY have to obsess over, or a standard that they should strive to live up to.

A lot of times, it's a lot like those guys who go out and beat golf-ball sized dents all in their sexy little corvette -- it makes it more aerodynamic and gives 2 extra mph to the top speed!! Does it work? Sure!! But does it make it look like crap and lower the resell value for anyone else in the world....