Ask HN: Going from programmer to engineer - <AUTHOR> Hey HN,
Long time lurker. I've finished up enough schooling to become a mediocre programmer. What I mean is I've learned enough C and done enough labs like implementing a paging algorithm or building a socket to be considered a mediocre programmer.
I want to take it to the next level though. I have plenty of ideas that I think up of where I'm like "why can't I just write software to do this, it'll be much easier". However, every time I sit down and try to learn MVC or django or iOS to implement my ideas I usually get stuck and flail and call it quits. Kind of a shame, I know, but I need some advice on HOW it's done. What resources or books do you use to go from someone who can do some kinda cool stuff to really cool stuff? I'm looking for that jump from amateur programmer to someone who can build a web app after a good few months.
What resources have you used to get there? <comment><USER2> Maybe start with microframeworks. Something like Flask (Python), Express (Node.js), or Sinatra (Ruby). Once you get a bit comfortable in them start using template engines to separate your logic from your presentation. Then look at adding libraries to support different storage engines, etc.

Using microframeworks, you will basically have to implement a lot of things from scratch, but you'll end up recognizing the patterns of common web application development. Knowing these patterns will make it easier to learn monolithic web frameworks like Django. It'll also motivate you: at some point having to reinvent every wheel gets old.

Try a lot of things and make lots of mistakes. At some point it'll all just make sense.

</comment><comment><USER3> IMO, find an open source project on Github that you think is cool and is, at least, partially working. Then eyeball the code, ping others working on the code, etc... You should be able to find a project that is a good fit.

Because you'd be joining a project with other devs working it, you'll be able to start with small changes and progress to bigger ones. As you're not the only dev, you don't need to get the whole thing done, just your little piece.

As the project already exists, you'll be able to look at the code's design and work with the other devs to learn.

Like you, when I wanted to learn Ruby, I was nervous biting off a big project. So I worked on the org-ruby gem. I only made a tiny mod to it but that gem is one of the gems that Github uses. IMO, that's very cool.

You can look at the pull request history for the work I did at <https://github.com/bdewey/org-ruby/pull/20> \- If you read the interchange I had with the developer, you'll see that he really helped me understand Ruby, Rakefiles, and the org-ruby gem.

I imagine that the gem owner spent more time helping me than it would have taken him to implement what I did, but he seemed happy to help.

When you think you've found a good project, you may want to send the devs the question you posted here and see what they say. Perhaps they'll be thrilled about the help, perhaps not. Better to figure it out before you start.

<comment><AUTHOR> Wow - totally forgot about Github, after reading your exchange I think I certainly have a new avenue to look into now. I know reading about programming is never a good substitute for actually doing, but seeing other code helps out tremendously. Thanks!

</comment></comment><comment><USER4> You really can't go wrong here (ish). I recommend picking a language/framework you are comfortable with and just start building something. PHP, Python, or whatever. Just dive right in. There is no secret---just try, make mistakes, learn from them, try again. repeat.

</comment><comment><USER5> I'm a mechanical engineer who taught myself to code and now I've written a full-blown web app. I'd recommend jumping right into Rails and building and breaking stuff, which is how I learned.

On the plus side:

-There's a TON of documentation, resources and help online.

-It's really fast to get started, so you'll get quick wins. This is key for motivation.

-It will slowly introduce MVC to you, but you don't have to build it yourself to get started.

On the minus side:

-There's a lot of 'magic' stuff going on, which can be confusing when you're used to explicit C code.

<comment><AUTHOR> Heh - its funny, I was really unnerved at my last internship where I was using PHP, it felt so weird with all this abstraction because of my C background but it felt really nice being able to not worry about to details and let the magic take over as you stated.

Anyway, when you say Rails, are you talking about RoR, or just plain old Rails (is there a difference)? The stuff you learn from rails, did it teach you good software engineering or mostly implementing a specific type of web app?

Thanks for the advice though. Giving this stuff a try now!

<comment><USER5> Yeah Ruby on Rails (same thing).

After building something for a couple months I feel like I have a decent grasp on MVC, which is the biggest win. I also have a lot better grasp on all the moving parts of a web app (website) -- how requests are routed, how it interfaces with the database etc...

</comment></comment></comment><comment><USER6> Just do your own thing. I wrote a lot of PHP when I was learning 10 years ago. Because it was PHP everywhere and that's all I had in hands. Do I do a lot of PHP today? Nope, occasional hacks and quickies, that's it. But from there I went to actionscript, javascript, C#, Flex / WPF / Silverlight... Touched C, C++, Haskell, Python, Go... Heck I even have some Haxe on my computer.

Whatever you have in hand, pick it up and do stuff. Pick a language that you can run easily, debug easily, and that is mature in the sense that whatever you google for, you will find. Try and pick a project that you are passionate for and open a github repo and give it your best shot. Try and implement the same thing in different languages if you think it's fun, or try tackle large problems with simple solutions that may only work 60% of the time.

Who cares, just do stuff that you can then show. Get an internship anywhere, stick in for a year or two. Then move on to the next place. Surround yourself of smart developers. Seek them and see how they think. Not wankers, genuinely good people. Not only they know their job, but they will love passing on knowledge. Ask them to review your stuff, bounce ideas, dumb questions, everything. That's far better than books IMO.

One thing is for sure, I don't learn much from books. Books help when you have a very gritty issue you feel totally helpless against. But most of the time, books as thick as bibles will drain you and turn you off and make you call it quit.

It's a computer, it can do anything. Period.

EDIT: do read books still, watch talks, they greatly open the mind.

<comment><USER7> > It's a computer, it can do anything. Period.

Anything? I assume you mean it can compute anything, right?

So you could write a computer program that determines whether two distinct programs do the same thing? Or whether a batch job will ever finish? Or whether you could substitute the variables in a equation with integers in order to satisfy it? Or a hundred other tasks that have been proven impossible?

<comment><USER6> Of course it can't do anything. The computer just hasn't found the person to tell it how to do it yet.

<comment><USER8> No; the halting problem (etc.) is unsolvable. We're not just waiting for someone to figure out how to solve it.

</comment></comment></comment></comment><comment><USER9> How do you get stuck? Are there actual technical or pedagogical barriers, or do you simply get bogged down in the amount of stuff to learn?

If it's the latter, I think some structure and simple project management could help. Break down your projects into smaller, more manageable parts that you can focus on and actually complete before you get stuck.

"Nothing is particularly hard if you divide it into small jobs." \- Henry Ford

<comment><AUTHOR> I think the first part -- what I've learned in school has given me a good foundation to programming, but I'm not sure how to take functional C programming and make web apps out of my knowledge.

I've tried reading some tutorials and there is also a ton to learn, but it's mostly the pedagogy of learning something like MVC. Although, I certainly agree with what you're saying about dividing. That does help me nudge further along anytime I attempt these projects.

<comment><USER10> MVC is just a design pattern. Nothing magical. I'm sure you came across many other patterns whilst learning C programming.

</comment></comment></comment><comment><USER11> For me, motivation is key.

I pick something I want to make, and make the feature that provides the most "bang for my buck" per say.

IE: When I tinker around with my Arduino Uno, I always try to get something to move first (turn the motors). Huge motivational boost for me. THAN, I figure out how the heck to get it to talk wirelessly with my laptop.

</comment><comment><USER12> Stuck learning Objective-C? This should kick you off: <http://www.youtube.com/watch?v=1Xqn5IHbusA>

65 really simple to follow tutorials, most of which are 6-7 minutes long. He does tutorials on pretty much everything; from iOS to go kart building.

</comment><comment><USER13> If you find yourself stuck anywhere with MVC or Django or iOS or anything else, going to <http://stackoverflow.com/> will almost certainly save you time and frustration.

</comment><comment><USER14> Dude, you will need to jump in, and preserver with it. You said "my ideas I usually get stuck and flail and call it quits", quitting means that you will stop learning. As soon as you quit, the game is over. Persistent is one of the key ingredient to gaining the knowledge.

I think that you should join an open source project that uses the same framework that you want to learn. There are plenty of projects from github, source forge, bitbucket, google code etc. That way, you get access to already code that is working, and able to get some guidance from the folks already working on the project.

Good luck!

</comment><comment><USER15> This is what helped me.

1\. Focus on one simple app, one framework(I'd recommend Django over Rails if you are new to web development), one reference book (<http://www.djangobook.com/>). Quick goals and instant gratification helps when you are starting out. 2\. Reading the relevant chapter(s) of the book before starting the implementation has worked better for me. 3\. Build the UI first (use Twitter's Bootstrap to get this done quickly). I am more motivated when I 'see' the end product.

</comment><comment><USER16> Focus and diligence are probably the most important tools to succeed as a software engineer. Also, having lots of mental stamina is helpful. You read the tutorial, write code, get stuck, take a break, re-read the docs, write more code, repeat. Only way to do it...

Possibly collaborate with somebody? Some people work best alone, but pair programming or working with someone else can help you stay focussed, learn and teach with others, etc. Good luck!

</comment><comment><USER17> One small step at a time. It doesn't matter what platform, framework or language, you pick a project and figure out what simple thing you can do to start.

You make mistakes, fail, backtrack and all of that is necessary to reach your goal. Amateur or not, everyone gets stuck and flails around for awhile. The difference between the person who has a few app a few months later and the person who doesn't is whether they kept going when they got stuck.

</comment><comment><USER18> The best resource is building something you consider useful. Start small and make it a personal project. Don't even think about making money on it or else you will destroy the enjoyment of making it. It doesn't have be long term, in fact it is better if you don't plan on maintaining it but instead build it and evolve it with every iteration.

</comment><comment><USER19> I've started and stopped programming, but feel like <http://www.teamtreehouse.com> has been really helpful. They have lots of videos to help fill gaps in knowledge, with a bunch on building web apps from start to finish, including RoR and other languages/frameworks.

</comment><comment><USER20> How you deal with the frustration associated with learning programming plays a huge role in how far you'll go. You can't read a book to learn how to press on when frustrated. The best engineers that I've ever worked with had an uncanny ability to motivate themselves through those intense moments of frustration.

<comment><USER21> Marco Arment had a good quote about frustration: "And there will certainly be hard parts: you'll get frustrated, go to Google, find some guidance, bang against it for a while, then finally get it working and experience immense satisfaction for as long as you can go before hitting the next wall of frustration. Fortunately, as you get more experienced, you'll hit those walls less frequently."

[http://www.marco.org/2011/02/01/how-should-i-get-started- wit...](http://www.marco.org/2011/02/01/how-should-i-get-started-with- programming-which)

</comment></comment><comment><USER22> its simple: try harder! learning a language is usually much easier than learning to use a framework efficiently. it just takes time and a lot of motivation. so its completely normal that you get stuck.

</comment><comment><USER23> It's kinda funny, because I often think this way but in the opposite direction. How the hell does one build a socket anyways? (Yes I will go and google this now so save your lmgtfy links :))

</comment><comment><USER24> Buy an Arduino and hack on it! It will open a lot of mental doors for you.

If you're not down with electrical engineering, just start a web project. I've found the easiest way to learn is to do.

<comment><AUTHOR> I've actually used an arduino before in a robotics class, was loads of fun and something I enjoyed!

Although, I'm sort of looking into building some web / mobile apps now.

</comment></comment><comment><USER25> You can ask yourself a few questions and get started accordingly. For example, what languages are you interested in ? PHP ? Python ? Java ? Pick up 1 of them. Since you mentioned Django,I assume you are working with Python. But then, play around with at least 2 frameworks. May be try Flask (micro- framework in Python) which I am falling in love with. Build the same app in both frameworks. I personally did User management/registration app in both Django and Flask. Start small. Build layers on top. There is no one way of course but building a few small apps just for learning will help tremendously.</comment>


Octopart Pocket Electronics Reference PCB - <AUTHOR> http://crowdsupply.com/octopart/octopart-pocket-electronics-reference-pcb <comment><USER3> I bought a set of these a few weeks ago.

[https://www.tindie.com/products/NsN/pcb-color-sample- set/?pt...](https://www.tindie.com/products/NsN/pcb-color-sample- set/?pt=directsearch)

</comment><comment><USER4> This is lovely.

One gentle suggestion for version 2 is conversions between pico, nano, and micro farads, and the capacitor codes used for these. Because even though it's easy to do it's still nice when you're feeling cognitively challenged to have a cheet sheet.

<comment><AUTHOR> Thanks Dan! Maybe if this one goes well I'll get to do a sequel :)

</comment></comment><comment><USER5> Hmmm, meybe i'm getting this wrong, but... Isn't a color code too basic to be in a card in your pocket?

I mean, c'mon, i haven't used color codes since High School about 17 years ago and i still remember how to decode them. It's not that hard.

i feel that consulting a table is more time consuming that knowing how to decode it... Usually while working with prototyping you end up with lots of resistors, and i can't see someone checking each one at the time against a table to reveal it's value...

But maybe i'm getting it all wrong, someone?

<comment><USER6> If you're breadboarding a lot, or manually stuffing printed circuit boards, or otherwise doing manual assembly in some way, you quickly learn to read most common ranges of values on sight. Maybe some people like to keep a reminder around for when you encounter weird values, or when troubleshooting.

</comment></comment><comment><USER7> Like the SM footprints, but I'm not sure I see the point of the resistor color code chart these days (If I do spec a through hole resistor, 99% of the time it'll be a 1%).

<comment><USER4> Not sure I understand - Vishay[1] MRS25 resistors are 1% and use a colour code. ([http://www.vishay.com/docs/28724/mrs16m25.pdf](http://www.vishay.com/docs/28724/mrs16m25.pdf))

They're generally pretty nice as resistors go. Do you spec better than that?

[1] I used these when they were Philips, which shows how long it is since I was doing this stuff.

<comment><USER7> The 1% series has an extra value band, which throws off their multiplier. Example: 1k 5% is brown black red (gold), but 1k 1% is brown black black brown (brown).

We do use a few 0.1% values in some cal equipment--about $1 each!

</comment></comment></comment><comment><USER8> This is way better, too bad it's over. :(

[http://www.pozible.com/project/31806](http://www.pozible.com/project/31806)

</comment><comment><USER6> Does "Set of Reference PCBs" mean four for $32.00?

edit: nevermind, I scrolled down far enough to find it.

</comment><comment><USER9> I prefer using a multi-meter. That might be something to do with being colour- blind though.

<comment><USER10> That's a pain-in-the-butt way to find the one resistor you need in a pile of fifty. Even though you are color-blind, that's just red and green, so you too can say to yourself "blue, blue, I need two blue stripes..."

<comment><USER4> That's a weird mis-characterisation of what it means to be colourblind. It's one of the discriminations that's still legal in England - <USER2> companies are allowed to not employ people with colourblindness because of the lack of suitable 'reasonable adjustments' and the need to have colour vision for a lot of electronic stuff.

Also, any resistors not in a pcb should be in a nice drawer with a neat label; any resistor in a circuit could give misleading values when multimetered because it's in a circuit.

<comment><USER10> _That 's a weird mis-characterisation of what it means to be colourblind._

I thought male pattern colorblindness (far and away the most common type) simply means the inability to distinguish green from red, not total lack of color vision. Hence why I would expect you could still locate resistors with blue bands.

 _any resistors not in a pcb should be in a nice drawer with a neat label_

"Should" being the operative word here. If that always happened, we wouldn't have bothered to give resistors identifying marks.

<comment><USER4> > If that always happened, we wouldn't have bothered to give resistors > identifying marks.

Yes we would, because we need to know what that resistor is when it's in a PCB. We can't measure it because it may be in parallel with other resistors.

> Hence why I would expect you could still locate resistors with blue bands.

Can you identify what the colours of this image should be? (Ignoring the massive clue in the filename.) :-p

([https://en.wikipedia.org/wiki/File:Rainbow_Deuteranopia.svg](https://en.wikipedia.org/wiki/File:Rainbow_Deuteranopia.svg))

That's for a severe form of the most common form of color-blindnes.

([https://en.wikipedia.org/wiki/Color_blindness#Classification](https://en.wikipedia.org/wiki/Color_blindness#Classification))

<comment><USER10> _Yes we would, because we need to know what that resistor is when it 's in a PCB_

Why couldn't we just label the resistor with silkscreen? We already decided labeling their drawer was better than labeling the resistor, so why not apply the same to the PCB? Easier to read silkscreen than color bands anyway, right?

 _Can you identify what the colours of this image should be_

I said blue. Notice the blue is quite easy to spot in the image you linked. Of course it would still be a pain to try to find the 10k resistors by color, yes, I know that. But at least the color bands wouldn't be _totally_ worthless.

<comment><USER4> > Why couldn't we just label the resistor with silkscreen? We already decided > labeling their drawer was better than labeling the resistor, so why not > apply the same to the PCB? Easier to read silkscreen than color bands > anyway, right?

Some resistors are labelled with silkscreen. Those resistors are expensive 1%, 0.1%, or 0.01%.

For run of the mill resistors it's cheaper to use colour coding. Also, when assembling a PCB it's good practice to keep the codes visible. That takes extra time for human operators. I don't know how machines do it for conventional components.

Labelling the PCB is important. There's a space marked R1, and a parts list telling us what R1 should be. There's a resistor in that space. How do we know what that resistor is? We read the color code, or the marking on the device.

There could have been a mistake at the resistor making factory, so we have a goods-in inspector who does some checking of the goods coming into the factory, and we buy from quality vendors and quality manufacturers. We hope the ISO 900x accreditation means something; we hope the certificates of conformity mean something.

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> It's fun, but I'm not sure what it's for as I can look up these things on the internets if I forget. Is this just an executive engineer gadget?

<comment><USER6> It would be a good thing for my students to have in their kits. I try to get them to make something similar for SMT footprints every year (to print out on paper) with varying amounts of success. It is easy to get confused on different size designations (QFP, TQFP especially), and there is not a lot of utility in making people memorize stuff like this.

<comment><USER10> Package types are not size designations. Pin count & pitch matter more than QFP vs. TQFP, and the dimensions of one manufacturer's TQFP can easily be different from an others, so the datasheet is key.

<comment><USER4> Yes, for designing a product people must refer to a datasheet.

But when discussing things it's nice when someone can correctly say "TQFP", or when they see a choice of two ICs and you say "It's the QFP one" and they can pass that tube over.</comment></comment></comment></comment>


Tell HN: Twitter's API v1 has been deprecated. Update your clients - <AUTHOR>

Hello everybody.
I'm posting this to let you know that Twitter has retired API v1 just 3 days ago. Clients that rely on this API should be updated.
I'm seeing A LOT of broken implementations everywhere.
This applies to every use of Twitter's API, from tweet bots to full-blown apps.
More info here: https://dev.twitter.com/blog/api-v1-is-retired
Have a nice day ;) <comment><AUTHOR> Clickable: [https://dev.twitter.com/blog/api-v1-is- retired](https://dev.twitter.com/blog/api-v1-is-retired)</comment>


Sriram Krishnan On leaving Microsoft - <AUTHOR> http://sriramk.com/leaving-microsoft.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+SriramKrishnan+%28Sriram+Krishnan%29 <comment><USER2> I'm not sure what I have learned here or why this is important to be mentioned here. Guy is leaving Big Corp (TM) and moving to San Francisco to build stuff. He says some nice things about said company and that's it. So, what else?

 _Edit:_ And this was almost a year ago...

<comment><USER3> It is worth mentioning he has been an active member of the HN community (<http://news.ycombinator.com/user?id=sriramk>)</comment></comment>


Insomnia Month 5 Recap – First Revenue - <AUTHOR> https://insomnia.rest/blog/progress-report-2/ <comment><USER2> I love reading posts like this. Reading about the challenges you face is really inspiring and informative.

Looking forward to your next post. Good luck on getting to $100 MRR!

<comment><AUTHOR> Thanks! Hopefully you found it useful :)</comment></comment>


New Look at Mystery Flashes Reported by Astronauts - <AUTHOR> http://www.space.com/scienceastronomy/mir_lights_030416.html

<comment><USER2> "New" (in the title) = April 2003. Anyway, apparently if you're in space then sometimes cosmic rays interact directly with your retina or optic nerve, producing brief flashes of perceived light.

<comment><AUTHOR> Sorry about that. It was new to me and I my eye slipped right past the little date there.</comment></comment>


Don't Lie on Your M.B.A. Application - <AUTHOR> http://live.wsj.com/video/dont-lie-on-your-mba-application/9C27DD8B-EC24-4B32-9BE1-A411185AE2AF.html?mod=WSJ_article_outbrain&obref=obnetwork#!9C27DD8B-EC24-4B32-9BE1-A411185AE2AF

<comment><USER2> The video was quick and to the point.

I am glad that some take this into account, they want to produce the best, and keep a high reputation for trustworthy people.

To me, it is kinda scary that someone can find out (and verify) so much information. Where does this information come from? Aren't there things like FERPA in place to prevent academic records getting out to anonymous Joe Blow?</comment>


Ask HN: How do you manage working with multiple languages? - <AUTHOR>

Everyone has a language that they love working in, but sometimes the problems at hand require different tools. This may mean writing code in 2 or 3 languages a day. How do you write great code in any language while staying true to the language's ideals and not trying to transform it to work as other languages?<p>EDIT:  When working with C/Cuda, python, and perl throughout the day, I find myself being pythonic in perl, and whatnot, or not being pythonic in python after working in C/cuda.  Then I have to go back in refactor.  I'm sure I'll get used to it eventually, I was just wondering what HN does to keep their head straight. <comment><USER2> I personally try to segment my time so that I'm focused in one language at a time. This gives me an opportunity to search the web and read documentation on the language at the same time, so I'm improving my ability to use the language.

For example, I often work with Objective-C (iPhone/iPad) as well as Ruby + Ruby on Rails + HTML + CSS (backend). Some days I really need to work in both environments, but I try to spend most of my days focusing on one.

</comment><comment><USER3> I have to jump between JavaScript and Java at work. The biggest problem for me usually is the small syntax mistakes I create, e.g. using var in a java file or "int i" in a javascript for loop.

But I find the differences in syntax help compartmentalize how I code. As soon as I get the compiler error in the java file it jar's be back into the java way of thinking.

</comment><comment><USER4> I work on C# on the pc side and objective C on the iPhone side. I don't have a problem going back and forth. Try it out for yourself. I don't think its that much of an issue.</comment>


Giant 20-sided die on MIT campus - <AUTHOR> http://www-tech.mit.edu/V128/N14/graphics/gygax.html

<comment><USER2> Whew, finally hackers are learning not to use LEDs in anything; after all, all bombs _have_ to be covered in LEDs in order to blow up, and therefore any strange object with LEDs all over it _has_ to be a bomb.

</comment><comment><USER3> Nerd quiz: without consulting your own dice, which number on the pictured d20 is facing up?</comment>


Speed Traders Invade Sleepy Corner of England, Locals Bristle - <AUTHOR> https://www.bloomberg.com/news/articles/2016-07-28/speed-traders-invade-sleepy-corner-of-england-and-locals-bristle <comment><USER2> > for now at least, microwave signals are among the fastest ways to transmit > orders between exchanges.

I think the author could have asserted this with a little more confidence. Short of building a vacuum tube, which would be about 0.03% faster, microwave signal is (and will continue to be) the fastest way we of transmitting information from England to Germany, or from anywhere to anywhere else for that matter.

Although, if anyone is going to completely overhaul our understanding of physics and develop faster-than-light communication it'll probably be high- frequency traders. I think Wall Street already hires more physics PhDs than all the universities in my country combined.

<comment><USER3> Sad waste of talent, just like all the people trying to figure out how to get more eyeballs on advertising. Physics people trying to eek out a millisecond or two out of a trading system in order to front-run order books just seems so trite and short-sighted. It's personally very disappointing that we exist in an economy which so highly incentivizes this type of endeavor.

<comment><USER2> I agree, but I think a lot of those physicists would love to work in physics if they could find a job. No one spends 6 years studying neutrino flavours because they want to make tons of money working in finance.

</comment></comment></comment><comment><USER4> For original, in-depth, on-the-ground, and ongoing commentary on HFT developments in this region I recommend reading the "Sniper in Mahwah" blog(1). It gets a lot more technical, among other things. His posts are regularly featured here on HN(2).

(1)[https://sniperinmahwah.wordpress.com/](https://sniperinmahwah.wordpress.com/)

(2)[https://hn.algolia.com/?query=sniperinmahwah](https://hn.algolia.com/?query=sniperinmahwah)

<comment><USER5> Also of note, Mahwah is the small town where Wall Street effectively moved to.

</comment></comment><comment><USER6> Yet another case of NIMBYism. Why does the community get to decide on what is done with private property? A radio tower mast harms nobody, will not significantly affect traffic, utilization of public utilities, or pollute.

It's telling, the comment at the end. 100,000 pounds? Not enough. We need to extract more from those evil financial companies, because they can afford it. What a naked money grab.

<comment><USER7> > What a naked money grab.

Whereas high frequency trading is what, exactly?

It'd be one thing if the radio tower were needed to serve a useful purpose, but why should they be able to impose it on a community to shave a couple milliseconds off of latency so financiers can play stock market games?

Maybe I'm not well educated on the issue, but is HFT not just a gigantic zero- sum arms race where the participants would all love to stop wasting money on it except they're worried that someone else would one-up them by half a millisecond?

<comment><USER8> This is a straw man reply. It isn't responsive to the original objection -- why should the government get to decide whether someone can build a radio tower on private property, provided that it doesn't adversely impact anyone else? The proposed use of the tower is irrelevant.

<comment><USER7> I don't know what the land use laws are over there, but I can tell you that in the US, the government _frequently_ gets to decide whether someone can build a radio tower on private property.

I'm fairly certain if someone bought a plot of land near me and said "I'm building a 1000 ft. tall radio mast for stock trading" they'd be promptly told to fuck off.

On the other hand, if a project is being built to provide a public benefit, say for an emergency radio system or something, then variances are more likely.

<comment><USER9> I don't think that answers they question of why the government _should_ be able to do so.

<comment><USER7> A more extreme example to make a point: because it would be bad if someone could buy up the house next to me, knock it down, and replace it with a sewage plant.

At least in the US, a large component of limiting land use is to prevent someone from moving in with some undesirable feature and tanking an entire neighborhood's property values, which in many cases are homes that represent a large fraction of a lot of people's net worth (and retirement funds). Taken too far, this can lead to crazy NIMBYism that keeps anything from being built anywhere, but I don't think it's unreasonable to say "No, you can't put a landfill in the residential area that's been developed here for 150 years."

Whether you think a 1000 ft. radio mast falls into that category is up for debate, but a full-on libertarian "I can do whatever I want wherever I want to" system wouldn't lead to very good outcomes.

<comment><USER10> You were probably exaggerating, but "I can do whatever I want" is far from libertarian. Indeed, forbidding imposing uncompensated the externality of decreased land values in this situation is one of the defining aspects of libertarianism as opposed to, say, anarchism or socialism (where you pay a fee to the government - excuse me, the People's Party - to do whatever you want).

<comment><USER11> You are correct, but I'd like to clarify that property rights on land is one of libertarianism's big things mostly because rich folk own a lot of land.

They'll defend having a "big government" that'll commit violence to protect rich people's land and they'll pay for that with taxes that they would otherwise decry as theft at gunpoint.

Contrast this with their general approach to industry dumping carbon or other pollution into the air and suggestions to price in those externalities.

<comment><USER10> You clearly have no clue what the term "big government" means. It doesn't mean your local Sheriff's office, at lower staffing levels than needed for the drug war.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> FWIW, said financial firms do pay very well for the rights to use those towers, and they almost always have to employ local or relatively local tower climbers and ground crew to maintain them. If Vodaphone wanted a tower in this town, it wouldn't be news.

Disclaimer: I work for one of the two companies mentioned as having applied for permits in TFA.

<comment><USER13> Pretty sure Vodafone would not be building one nearly as high.

</comment></comment><comment><USER14> Can the council build the tower and then rent space to the network operators, using the money to fund local services?

<comment><USER15> From a financial perspective it is not that costly to build a 300 meter guyed tower. FM radio stations in the Midwest and TV stations do it all the time. I've heard figures of around $2 million total for an 1800' in ND. Yes you could build a tower and rent space on it. Whether this makes sense for a local government to do is another question.

</comment></comment><comment><USER16> I keep hoping that some of this massive brain drain trying to shave off the last ms of latency (FPGAwork, microwave towers, etc etc) will somehow translate into some advancement good for the overall society.

Also, I hope the rapidly diminishing returns will stop this ridiculous arms race.

</comment><comment><USER17> Is there a reason these HFT firms can't put servers in a DC in Frankfurt? What am I missing?

<comment><USER18> They almost certainly already have servers in a DC in Frankfurt - the point is that being able to communicate current prices between the major markets faster than anyone else gives you a trading edge over other market participants.

<comment><USER17> Doesn't the trading logic live on that machine in the a data center in Frankfurt? It responds to signals and executes trades based on those signal correct? It doesn't require hitting an API like in a standard web app right? From my admittedly limited exposure to an electronic trading shop, that logic was maybe updated a few times a day but largely ran as a state machine based on signals and market feeds. What am I missing?

<comment><USER18> Sure, some HFT strats are locally encoded. But that's not the only way to make money. If what you want to do is run arbitrage between different exchanges then being faster than everyone else gives you an edge. You can take advantage of price differentials before anyone else does plus you get to front run news that has market impact round the world before anyone else can get their orders in.

There are plenty of ways to make money if you're faster than everyone else at getting data from exchange A to exchange B.

</comment></comment></comment></comment><comment><USER19> That's quite the long path over water. Hope they don't have strong temperature inversions there...

Perhaps the plan is to just quit trading when the link is down. Make money when they can...

</comment><comment><USER20> Why put it in a little village and not in the center of London? Cities (imho) are eye sore galore already so more eye sores don't really make a difference, while in a quaint English town it changes everything.

<comment><USER21> Because the earth is a sphere and microwaves travel in a straight line.

At my height, standing on the beach the horizon I see is only 5km away.

<comment><USER22> Huh, why does that make building it in the city / countryside any different?

</comment></comment></comment><comment><USER23> Why aren't they building a fiber optic link? Is it that the shipping channel makes it too likely for disruption of the link?

<comment><USER15> Light in fiber moves at about 0.66c due to bouncing off the walls of the fiber trillions of times in a short distance.

<comment><USER24> It moves at that speed because the index of refraction of glass is about 1.5. In single-mode fiber the light doesn't really bounce off the walls.

<comment><USER25> Also significant latency is imposed by the network architecture vs the choice of bearer, and by shared vs single user. My guess is that the main driver is actually to get a private channel with qos guarantees and as few retransmission hops and security bumps as possible.</comment></comment></comment></comment>


"My current theory is that programming is quite literally writing." - <AUTHOR> http://ask.slashdot.org/comments.pl?sid=2198700&cid=36293622 <comment><USER2> _Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel._

Let's get a little more specific...

Most code sucks because the programmer:

      - didn't name his variables what the really were
      - didn't understand variable state
      - didn't understand variable scope
      - didn't understand the basic concepts of iteration
      - didn't understand any of the algorithms he needed
      - wrote the same lines of code multiple times
      - didn't know enough about the language to find a better construct
      - didn't understand concurrency
      - didn't understand fundamental data base concepts
      - refused to follow well worn standards
      - didn't have any well worn standards to follow
      - built code on top of hopelessly designed data structures
      - didn't understand deeply enough what was going on under the hood
      - built to requirements that changed too dramatically to recover from
      - didn't even consider the concerns of the "next" programmer

But most of all:

      - was just good enough to get "something" (no matter how bad) deployed on time

<comment><USER3> I think you can check off everything on this list and still write inscrutable code. The worst code I've seen is code that was written so that only one person understands what's happening -- the author. Typically the code has too many branches and ridiculous call stacks. The writing analog is a run-on sentence.

This usually happens when the programmer at fault is really smart but still hasn't learned that at some point in the future, someone needs to come along and understand the code he/she wrote.

Maybe we need editors?

<comment><USER4> What you think code reviewing is for?

<comment><USER5> No, traditional code reviewing is just spot checking. That is analogous to having an editor only look at a few passages of a novel. An editor needs to work with the whole text. This is the trouble with formal code reviews. Pair programming attempts to solve this by making all code get reviewed as it gets written. Like it or hate it, that at least tries to solve the core problem.

<comment><USER6> I suppose we're not "traditional" in this sense, but at Facebook we do somewhat more in-depth code reviews than just spot checking. Generally if you're modifying an existing system, you get one or two people who're familiar with that system (and thus know the big picture of code design, layout, etc) to review your diff.

If you're writing something totally new, you usually throw ideas and mocks (either UI or code-structure) until you decide on a solution that works.

I've found this to be pretty good at helping newer engineers write good (and idiomatic) code without hindering development speed much.

</comment></comment></comment></comment></comment><comment><USER7> I think he's right.

In college, my CS 2 class was taught by a professor very different than the rest of the teachers there. He wanted all of your programming assignments on paper[1]. Then, you'd get it back with every possible bug marked in your program, and he very rarely missed any[2].

That was the first time in college I thought "I really need to learn how to do that!"

I went to a state school, so maybe all you guys with your degrees from fancy schools wouldn't be that impressed, but the difference between this professor and the rest there was gigantic. (He retired that year in a round of state- wide budget cuts, so that's the last class I had him.)

[1] A lot of the other teachers wanted you to hand in binaries so they can see it run. Sometimes with the code, sometimes not.

[2] I actually don't know of any case where he did, but I'm not saying "never."

<comment><USER8> From what I've heard, professors in prestigious schools aren't any better at teaching. They're hired for their prestige and research ability.

<comment><USER9> All true facts unfortunately. To get better teachers you have to attend a "teaching" college/university. This name is detrimental, as most students would probably be happier at such a place. The "research" university really isn't for everyone but they get the most prestige and people think, oh I should go there learn from the "brightest mind in the field".

<comment><USER10> The value of Stanford, MIT, CMU, etc. isn't that the professors are so good at teaching; it's that they are smart student aggregators. Nothing motivates you like not being the smart one anymore.

<comment><USER11> That might be true of some people. For someone coming from a small town where everyone told him that he would go on to do amazing, wonderful things, it can be very depressing for him to learn that he is nothing special.

<comment><USER10> That's more of a feature than a bug.

The opposite can be true too, I expected to get tanked at CMU and did pretty well (3.65 gpa, senior thesis, going to Facebook). If I'd gone to Ohio State like the majority of my peers from High School (Hilliard Darby High School has sent a whopping two people to top tier engineering schools (CMU and MIT) and none to Harvard) and even gotten a 4.0, I never would have believed I was more than a "talented state school kid."

At the end of the day, it's on you to put yourself in the most challenging situation you can possibly survive so that you can learn the most. Sheltering one's fragile ego never did much for anyone in the long run.

</comment></comment></comment></comment></comment></comment><comment><USER12> When you've learned two subjects with some depth, you start seeing some analogies. Paul Graham thinks that hacking is very much like painting, and this guy thinks that writing code is like writing English, and at one point in my life I believed that coding in Perl has a lot in common with calculating cross sections.

That doesn't really mean that these things are any more similar than two random areas of human activity. Our brains are just good at finding analogies, finding analogies is like spotting patterns, we see them even when there aren't any and when there actually are some their appeal is difficult to overcome. And if you know two subjects well you have more material to cherrypick analogous things from.

</comment><comment><USER13> > Japan is somewhat famous for churning out students who know a lot _about_ > English, but can't order a drink at Mac Donald's.

An old friend of mine had a master's degree in French literature. She used to live in Ottawa, Ontario and was fond of a pizza place just across the river in Hull, Quebec. One day she called to order a pizza, and when it came time to ask for it to be delivered she realized she didn't know how. She asked if the pizza place could put the pizza into a car and drive to her house with it.

The order taker replied, "Oui, delivery. Nous pouvons le faire."

<comment><USER14> Translation?

<comment><USER13> "Yes, delivery. We can do it."

 _Edit:_ \- I should point out that the French word for delivery is _livraison_ ; but like most languages, day-to-day Quebecois French is porous enough to borrow words from other languages where expedience warrants. Hence _le week-end_ (not _le fin-de-semaine_ ), _frencher_ (to French kiss), etc.

As a further digression, I should point out that it seems less common (i.e. less acceptable) to drop anglicisms into informal Quebec French than in Europe, where native French speakers do not feel threatened by a dominant continental Anglo culture. I was amused on a recent trip to France to learn that the French word for wifi is "wifi" (pronounced _wee-fee_ ). Since wifi is short for "wireless fidelity", a more canonical French term would be something like _fidélité sans fil_.

<comment><USER15> Of course, the French Academy tries to crack down on this; I remember cases like trying to push out "email" in favor of the native "courrier électronique" (literally: "electronic mail").

<comment><USER13> AFAIK in Quebec the preferred term is "courriel", which is a portmanteau of "courrier électronique" in the same manner that "email" is a portmanteau of "electronic mail". (Funny that we're talking about Anglicisms in French, given the vast number of English words of French origin - like "portmanteau".)

<comment><USER16> I remember reading that the word courriel is in fact a Quebecois invention.

</comment></comment></comment></comment></comment></comment><comment><USER17> He is exactly right.

As a beginning-programming instructor, my students have little difficulty understanding language syntax and operation - much like the "language lawyers" mentioned. Their recurring problem is not correct syntax, it's internalizing the process of expressing a solution to a problem using that syntax. They have few unto no examples of what a program - a real, functioning, well written program - looks like.

Indeed, programming is writing: it's expressing the solution to a problem using a formalized language. Understanding how the program works is one thing (and yes, all too often this is a problem); a good program also expresses why.

A 3 year old writing a novel won't succeed because, despite the ability to speak, he does not comprehend the process of concocting and presenting the story; all he knows is the minimum needed to just read one. He's not going to write good novels until he reads lots of good novels, and groks the literary structure and process of having and expressing an idea. Ditto programming: students may know the syntax, but they don't grasp the notion of "writing" because they haven't seen any decent examples.

Rosettacode.org may be a good starting place.

Thanks for the article, I may finally have identified the gap in my teaching. Now to find concise examples to fill it with, as the curriculum does not allocate copious time for reading lots of coding examples. Anyone have links to good examples for beginners regarding fundamental concepts? I don't mean syntax (I teach that well enough), I mean elegant uses akin to poetry or short stories. IOCCC (a moment of reverent silence for greatness ended) has wonderful examples of cool things in minimal code, but commands obfuscation. Anything akin to IOCCC for good readable nifty code?

<comment><USER18> How long have you been teaching programming, and how did you get into it? I'm very interesting in teaching beginner programming for a while now, as I'm completely unsatisfied with my "top 10 in CS" university's shallow approach. If you could drop me an email (in my profile), that'd be great.

</comment></comment><comment><USER19> I actually subscribe to the theory put forth in Structure and Interpretation of Computer Programs by Abelson and Sussman

[http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-9.html#...](http://mitpress.mit.edu/sicp/full-text/book/book- Z-H-9.html#%_chap_1)

Essentially, "computer science" is a myopic name for what is really "process studies." It just so happens that defining processes to run on computers is forwarding the field more than any other. But in the distant future we will all understand the field to be about abstractly defining processes i.e. a series of repeatable steps to accomplish a task. Which would be independent of the mechanism used to execute the process.

Therefore programming is the act of defining a process. And programming languages are what we use to define them.

It is covered fairly intuitively in the first few minutes of the SICP video lectures as well:

<http://video.google.com/videoplay?docid=5546836985338782440>

<comment><USER20> _Essentially, "computer science" is a myopic name for what is really "process studies."_

Actually the name isn't myopic at all. Computers are basically entities that follow instructions. There was a time when the definition for the word computer was a person who did computation processes.

<comment><USER21> James Gleick's The Information has a good description of those people, and is a great read otherwise as well.

[http://www.amazon.com/Information-History-Theory- Flood/dp/03...](http://www.amazon.com/Information-History-Theory- Flood/dp/0375423729)

</comment></comment></comment><comment><USER22> I'm a little suspect if this analogy goes beyond "theoretical understanding without practical experience is worthless". You could draw a similar analogy between architects who know everything about architecture but don't know how to design proper buildings because they have no experience. Or painter who knows everything about technique but can't paint a horse and so on.

It is easy to find differences between good writing and good code: Uniformity in code is good, while uniformity in prose is bad. In writing, a large vocabulary is an advantage, it's difficult to see if that is the case in language. In programming, proper abstractions are essential while I can't really see the equivalent of that in writing.

As far as analogies go, I can't see how this one is much better than others.

<comment><USER23> Uniformity in code is bad - it tells you that there's a common concern or pattern which should be factored out. Uniformity in code _style_ is essential, the same way it is for prose.

<comment><USER22> Is it? In prose you say "first he rushed to the exit door, then he leaped down the stairs, finally he ran to get the train" while in programming it is better to write

        socket.close(); window.close(); file.close()

<comment><USER24> Better prose is:

"He rushed to the exit, leaped down the stairs, and ran for the train."

Better programming is to factor out the action:

        [socket, window, file]*.close()

<comment><USER25> Just curious, is that taken from an actual language? Because I've wanted a feature like that for ages.

<comment><USER26> It exists in Ruby:

        [socket, window, file].each{|item| item.close()}

<http://codepad.org/GqNp94Iw>

It sort-of exists in Lisp-inspired languages (anything from Arc to Lua to Io) with appropriate boilerplate, for example:

        function apply(tbl, func)
           for key, val in ipairs(tbl) do func(val) end
        end

        apply({socket, window, file}, function (item) item.close() end)

<http://codepad.org/SNWO1Y6K>

<comment><USER27> It'll work in JavaScript, too:

       [socket,window,file].forEach(function(o){o['close']();});

<comment><USER28> And all of these ways are longer and less clear than the original. Better to write code like Hemingway than like Proust.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Actually the article is missing one thing. Yes, you need to be able to express yourself in the (programming) language.

But, and here is the thing, the hard part is not learning the words and the grammar, nor actually writing in the language using the said words and grammar.

No the hard problem is figuring out WHAT to say and HOW say it to make others (humans or computers, depending if it is a natural or programming language).

In terms if human language it is about formulating a narrative story that presents the problem and the solution to the reader.

In terms of programming language it is about describing the data structures, data transformations and transactions/communications needed to perform the task.

This is the hard part and that is what separates good writers and good programmers from their lousy counterparts.

BTW: I hope this was parseable.

<comment><USER30> I don't think this is missing from the article, it's actually what the author said. If you only learn the words and the grammar, without seeing how they are used to express things (and without trying to express things), you won't learn foreign language/programming.

</comment></comment><comment><USER31> Oh come on. Programming is not writing. When you're reading a novel you don't have to worry about concurrent access to a resource, threads, asynchronous events, or even much less conditional branching. With all due respect, I think this is just an inane post. That said, I can't blame the guy for dropping software development and moving to Japan to teach ESL. I often entertain similar fantasies all the time - programming is a great way to have the zest for life sucked straight out of you

Edit: Would someone have the courtesy to mention why they are downvoting?

<comment><USER32> And in programming you don't have to worry about capturing the audience, the development of the characters, the story arch, being clear but not being obvious, etc.

Both in programming and writing, the actual _writing_ part is the easiest part. And while bad programmers can make a program work, and bad writers can tell a story, it takes good ones to do it coherently, efficiently and enjoyably.

It's not the exact same thing, which I don't think anyone is saying, but there are some similarities there, especially the aspect of writing _readable_ code.

<comment><USER20> They're not nearly the same thing. The scope of modern literature has hardly moved in hundreds of years. Compare Updike, Roth, or Mitchell to Dante or Shakespeare -- they'd seem like near contemporaries in programming.

In contrast, in the past, programs to do Newtons method or compute trig tables were often the full scope of a program. You certainly never had a Halo 3, Windows 7, Google Search, or WordLens application written even 50 years ago.

Good _literature_ isn't about automating increasingly sophisticated processes. Programming is all about that. This leads to increasing complexity of programs, where the goal of software engineering is to abstract/hide as much of the complexity as possible.

The only things they really share in common is that they're both written in text. If programs were written by soldering wires no one would make such odd acquisitions (do EE relate circuit design to writing literature?).

I think we give this slashdot author far too much credit.

<comment><USER32> They have one more thing in common; the text is _read by other people_. And the better written, the more _effortless_ it is to understand.

I think this aspect of it is what the slashdot author is mostly talking about, suggesting that if you write code as if you were writing to the _next programmer_ , rather than to just the computer, your code will be better for it.

Clearly, programming and writing isn't the same thing. Nobody is claiming that and, _guaranteed_ , nobody here thinks that. It's a metaphor and like any other metaphor it breaks if you bend it enough.

<comment><USER20> Unfortunately, this metaphor breaks at the onset. Programs aren't primarily written to be read by people. They're primarily meant to enable functionality. Readability of code is important, but not the ultimate ends -- it is part of the means.

But the important part of my post was that programming is about automation. It's not about weaving a story, even for the next programmer. It's about building abstractions for automation. And yes, its important for other programmers to build on top or service it, but given a choice between the right user experience and dev experience, user experience should usually win (although there will be some exceptions).

<comment><USER32> The author argues that _good_ code _should_ be written for people. The metaphor doesn't break just because you disagree with the author's point.

IMHO, any dolt can produce code that _only_ works. All too often I have to sift through _horrible_ code that works, and I think the author is right in that if the programmer who wrote that (sometimes that's me, sometimes it's someone else) had had the next programmer in mind when he/she wrote it, it'd be much less of a pain.

<comment><USER20> _The author argues that good code should be written for people._

If good code were written only for people there'd be no quicksort. No fast implementations of FFT. Probably no fast versions of memcpy. The reason is that coding is not primarily about writing for other people. Look at Donald Knuth's code. Extremely well-written, yet certainly doesn't stand on its own. And there are certainly design decisions that optimize for both asymptotic complexity and small constant factors.

My point is that analogizing this to books does no one any favors at all. We're having a conversation on the merits, w/o having to allude to neither haikus nor novels, nor gerands, nor foreshadowing.

Programming is difficult, even for code that "only works" (you'd be a billionaire if you could find a way to quickly produce code that "only works"). It has little more in common with writing than tarot cards -- which also are made to be read by humans.

<comment><USER32> The author never claimed the code should be written _only_ for people, then it wouldn't work, would it? You're either trolling or mistaking the rest of us for complete morons.

<comment><USER20> _My current theory is that programming is quite literally writing._

That's what the author wrote.

Lets take another (stupid) quote from the author: _Most code sucks because we have the fluency equivalent of 3 year olds trying to write a novel._

There's no absolute nature regarding the state of ability for any given task. There is no way to map fluency in English to fluency in any other domain. It just doesn't make sense.

This is just all around lazy thinking. It's buying into a metaphor because you either don't have the ability or desire to actual think about the real issues. edw earlier in this thread actually took a little time to think about the issue. This slashdotter made no effort, had no substance, no data, just a cheap metaphor that fell apart upon first glance.

 _or mistaking the rest of us for complete morons_

How's this for lazy thinking -- I use duck typing.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> misuse-permit This is a decent analogy, but still I cringe whenever I hear someone comparing computer languages to spoken ones.

They are nothing alike, and I would be honestly surprised if we even used the same part of our brain for processing the grammars of human languages as we do for the rigid, formal computer ones.

If this were true, how come not all great programmers are great writers? Why don't more great programmers become fluent in other spoken languages?

<comment><USER33> >If this were true, how come not all great programmers are great writers? Why don't more great programmers become fluent in other spoken languages?

Why doesn't Mark Twain have any novels written in French? Why would you hold computer programmers to a greater standard than any of the great authors?

</comment></comment><comment><USER34> It's a nice theory but I disagree. Programming languages are really just a poor effort towards a mathematical notation.

There are those adept in theory that can't practice well, but that's because to practice the art means dealing with a plethora of hacks, exceptions and miscellaneous trivia completely unrelated to the core problem at hand.

Personally, I don't think the answer is becoming 'fluent' in handling the exceptions and idiosyncrasies of the chosen language, framework and platform. Rather we need to work on building a notation that provides better abstraction mechanisms.

<comment><USER35> How is mathematical notation different from a written language like English? It conveys meaning using glyphs, uses nouns and verbs (and even adjectives). It expresses all sorts of ideas. One might even say that math's notation is a poor effort towards English.

<comment><USER34> Language can be expressive in ambiguous ways, with multiple valid ways to express the same emotion. Notation should be definable, unambiguous, and precise. The fewer ways to express something, the better.

<comment><USER24> > The fewer ways to express something, the better.

Your last sentence could be rewritten "It is better to express things in as few ways as possible", or "Having fewer ways to express something is better". English, however, allows you to omit the main verb for the causation in a parallel construction, you were able to write it shorter, and with a 3-syllable climax after a pause at the end for effect.

Shouldn't programming languages also provide many different ways to express things?

<comment><USER36> No, because that makes it harder to understand what it's doing. Remember that programming languages are not learned at a very young age and continuously trained for decades the way natural languages are.

<comment><USER37> _No, because that makes it harder to understand what it's doing._

Without looking at an example of working code, how is it possible to say that one particular phrasing is so obviously better than any other that it and it alone should be allowed to exist?

I appreciate in Perl very much the postfix conditional expression syntax because it exploits the end weight linguistic property and allows me to emphasize the most important part of the statement when the situation warrants. I believe that makes my code clearer _because_ it looks different from the Algol-standard conditional syntax.

<comment><USER24> > Perl ... allows me to emphasize the most important part of the statement > when the situation warrants.

Yes. The ordering of elements in a sentence is its "thematic" structure, just as important in communicating as the "transitive" structure of sentences, i.e the relationship between nouns, verbs, etc. Most programming languages copy the transitive structure of natural languages, but not many allow the programmer to freely choose the thematic structure.

</comment></comment></comment></comment></comment></comment></comment><comment><USER38> Programming isn't about writing. It's about logic. It's a series of instructions for a computer to follow.

The old 'write down how to tie shoes' or 'write down how to make a peanut butter and jelly sandwich' projects show just how hard it can be to pin down exactly what needs to be done to do seemingly simple tasks.

The writing is merely how to you transmit the logic.

<comment><USER39> I disagree _so_ hard. Computer programs should be written primarily for humans to read, and only incidentally to be executed by computers. The connection between writing and programming is vital: they are both the practice of _expressing structured ideas_. It has nothing to do with the computer. It has nothing to do with the English language, or Vim, or Word. It's about starting with an idea and hacking away at it, removing ambiguities and possibilities, until only something unique remains.

<comment><USER40> _I disagree so hard. Computer programs should be written primarily for humans to read, and only incidentally to be executed by computers._

The funny this is that the same is also true for mathematics.

Mathematicians writing proofs and theorems are communicating with other people, not (usually) with machines.

Mathematical notation is s means of human-to-human communication. Yet anything but the most trivial math soon becomes inscrutable to the untrained. As far as I can tell, mathematicians are mostly happy with this. The language used allows for precise, compact expression of complex (i.e structured) ideas. That understanding requires training and rigor is not considered inherently bad.

For whatever reasons the same terseness and concision is derided by many programmers who seem to believe that ease of understanding by the moderately skilled is highly important.

</comment></comment></comment><comment><USER41> His theory might be true if you were only talking about writing a program from scratch. But programming is a lot more than that, because except for the smallest, most trivial exercises, programming is a team sport. Which means you need to be able to understand somebody else's code, and you also need to be able to modify it in a way that makes sense.

You can have a program which is beautifully structured, and factored in an extremely clean way. But what happens when you have to modify it in response to a change in requirements? And what if you have external code that depends on the existing interfaces? At that point, the skills needed to be a good programmer are quite different from that of a writer.

<comment><USER30> Ask a novelist about the pains they have when the extremely clean, excellent plot fails due to some small point, and they have to adjust it.

<comment><USER41> I can think of a number of novels where it's obvious some scenes got moved around for plot reasons, and their were continuity errors or other ways in which the seams showed.

But novelists only have to deal with that for maybe a year or so; programmers have to deal with this problem for potentially decades, and at that point it's a completely different problem just because the scale is different.

<comment><USER42> I'm working my way through Stephen Donaldson's latest Thomas Convenant novel (book 9), a series he started writing in the 70's (first book published in '77). He expects to have the final book (book 10) completed by Fall 2013

</comment></comment></comment></comment><comment><USER43> I disagree.

Programming definitely requires writing skills (expressiveness and concision most importantly)

However it's about structurally combining that writing into maintainable code, using idioms of the past to build upon to gain error free use. It's about mentally modeling what parts of the machine are doing, and correctly understanding those interactions. It's about risk assessment, experimentation, knowing when to call something quits. It's about going back over old world to do it a better way. It's about decomposing a complex process into many simpler steps. It's about reading, reading lots in fact, usually reading to find out details of the bits of your mental models.

Programming really isn't anything other than programming. It's not any field like it or near to it that knowing a nearby field plays well into it (electrical engineers can make horrible programmers but brilliant electronics guys same goes for web designers), but lots of other skills parlay well into getting you partway into the panoply of skills that get you past the finish line.

People make bad programs code when they only have part of those skills (or when they do not put out the effort to use the skills they have, due to time or willpower restraints).

Another reason some programs suck: they picked the wrong problem to code.

</comment><comment><USER44> "Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer." -- Edsger Dijkstra

As a programmer coming from a linguistics background, this sentiment has always resonated with me. As much as math is a part of my job, recognizing the transferrable skills from human language use has probably been the primary reason that I've been able to land programming jobs and write fairly successful code.

</comment><comment><USER45> That reminded of this quote (I forget who said it):

" _Programs are written for humans to read, not for machines to execute_ "

<comment><USER46> That was at the beginning of SICP.

</comment></comment><comment><USER47> To have good taste is one thing (the ability to recognize good from bad) but to be able to produce good work is another. As many good writers (and the author of this post) suggest, the best way to get better at writing is to read good writing and to write more. This method (of observing masters at work and practicing the craft yourself) works for many disciplines. Should it be surprising that it applies to hacking as well?

The post reminded me of an Ira Glass interview where he comments on having good "taste" (5 min) <http://www.youtube.com/watch?v=BI23U7U2aUY> which in turn reminds me of PGs essay "Great Hackers" <http://www.paulgraham.com/gh.html> Good stuff!!

</comment><comment><USER48> So what's good example code?

Sadly (and tellingly) it's not necessarily the most successful code (success comes from meeting user needs, not from good code), but how else can you judge it, apart from reading it. This is made worse because it's hard to tell if code is _necessarily_ complex without understanding the problem it solves, which may be complex. Further, if you don't yet know what good code is, how can you recognize it? Of course, if you are intelligent and reflective and try ideas out, you can learn from both code and bad - it's all raw material, grist for the mill.

IMHO the hard part of programming is understanding the problem to be solved. The solving is easy.

<comment><USER30> _Sadly (and tellingly) it's not necessarily the most successful code (success comes from meeting user needs, not from good code), but how else can you judge it, apart from reading it._

Schools have suggested reading lists. Do they have the same for _code reading_?

Fortunately, on the Internet, we have experienced people to help us: [http://www.hnsearch.com/search#request/all&q=%22good+cod...](http://www.hnsearch.com/search#request/all&q=%22good+code+to+read%22&start=0)

<comment><USER48> > [suggested _code reading_ lists]

That's a good idea, but I haven't heard of one. I think the best thing is just to read a lot of code, good and bad.

BTW did you check the result of that search?

<comment><USER30> _BTW did you check the result of that search?_

Haha, just skimmed through it, sorry. I remember threads on this topic, but it seems like HN search for this request failed to find them.

</comment></comment></comment></comment><comment><USER49> Isn't this the same thing Bruce Eckel wrote a couple of years ago? <http://www.artima.com/weblogs/viewpost.jsp?thread=255898>

</comment><comment><USER50> Saying programming is writing is like saying building something is 'speaking to materials'.

When you look at software, what you see is not a language, it is a _machine_. A machine that is presented in humanly understandable and communicable form, but nonetheless, something with a particular kind of underlying determinate structure.

Yes, the main part of the conclusion is the same: you have to learn by doing. But because software is _design_ \-- rational manipulation of objective 'material' -- knowledge _about_ how it works is also an intrinsic part of doing it well.

Design means creating something through clear knowledge: we go with particular design ideas because we can predict their outcome and effect. This is the knowledge _about_ that the article underestimates. We choose quicksort not simply because we have immersed ourselves in social norms, but significantly because it has been proven asymptotically fastest.

That kind of determinate knowledge that programming by nature can have is important. It is missing something to lump it in as just being like spoken language learning.

</comment><comment><USER51> He is right. Good writing is sussicint, concise, and says a lot with a little. Good programming is clear and does a lot with a little.

<comment><USER52> In some cases good writing says a lot with a little, but by no means is that always a requirement for good writing.

</comment></comment><comment><USER53> I agree with him. As kylematthews points out, it's not about the substance of the thing--capturing an audience, I/O calls, or anything like that. It's about communication.

Communication is about translating something conceptual inside your own head to become understandable by something (usually a person) outside of it. The way we do this is by language. A programming language is merely the way we communicate with a computer. To do it right, you need to understand the parts of the computer that you want to change.

It's not a mistake that we used to call impressive coding "wizardry" or "deep magic". It was about casting spells... except that if you actually step to the side and look at what "spell" means, it's simply a story.

A good program tells a good story. You might not appreciate the characters or the plot, but the computer sure does.

</comment><comment><USER54> I don't think that I can agree with the op on slashdot.

Programming is not about knowing lots of words or grammar. It is about getting the thoughts clearly structured and understanding quickly what a problem is really about.

THIS is quite the same problem as writing text. But, IMHO, the author approached this as someone who does not know how to write text, too. Its not about ingenuous choice of words and correct application of grammar. It is about clarity of understanding the problem and then find a solution how to get to the point clearly and quickly.

If a solution is in the mind, 70% of the way is gone. Then it is important not to give up unless this idea is on paper in the same shape as it was in the head before. So I think the analogy is a good one, but the op has not necessarily found the reasons why.

</comment><comment><USER55> I spent two years living in a foreign country learning a new language (my first foreign language) immediately before I started learning to program and it's always struck me how similar the two experiences are.

All good communication comes first from good thinking. Whether or not we can communicate in a certain medium (speaking a language, writing, painting, music, programming) depends entirely on how fluently we can translate our thoughts into that medium.

So good thinking + good understanding of programming concepts = good code.

</comment><comment><USER56> This makes me think of people who would try to "memorize" for e.g. science tests. They were ok as long as they could plug and chug, but they couldn't derive anything on the spot.

I'm wary of tickling my ego, but I recall not entirely seldom forgetting a formula, and so simply starting with other stuff and deriving it in the margin or on scratch paper. I think many of the instructors liked that, as well, as it showed a more conceptual grasp.

</comment><comment><USER57> This discussion brings to mind Robert Lefkowitz's Pycon keynote from 2007 on Programming Literacy, very similar to this video from Stanford: <http://www.youtube.com/watch?v=Own-89vxYF8>. He is definitely an advocate of literate programming and basically says we will all be able to read programs when they can be written in English and not in code.

<comment><USER50> > we will all be able to read programs when they can be written in English and > not in code.

Anyone thinking along those lines needs to read Dijkstra: [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html) (and maybe tack this on too: <http://www.hxa.name/notes/note- hxa7241-20101218T2158Z.html> ).

</comment></comment><comment><USER58> Literate Programing <http://en.wikipedia.org/wiki/Literate_programming> ?

<comment><USER59> Everything old is new again. :)

</comment></comment><comment><USER60> I like the author's premise. It's hard to find good writing that hasn't been rewritten.. a lot. That seems true to me about code as well. Perhaps we're seeing a lot of "rough draft" code being pushed to production. Novels never get published like that (hopefully!).

</comment><comment><USER61> I find it fascinating that Python seems to be the only language which created a word to describe idiomatic code: pythonic.

Having learned Python as a first programming language I always try to gain an idiomatic understanding of the language which allows myself to think in Python.

<comment><USER23> Rubyish, perlesque, lispy are all words I've come across.

<comment><USER62> I've also heard 'Forthy'.

</comment></comment></comment><comment><USER63> The only problem I see with this is when Bob, David, Mike and Steve have their own ideas about writing a story and take your love story then turn it into a science fiction novel about aliens, cowboys, race cars and heavy metal.

</comment><comment><USER64> No, its a kind of data. It has more in common with a spreadsheet than a novel. And like a spreadsheet you can get yourself into lots of trouble if you don't format the data in a way that suits the tool you are using.

</comment><comment><USER65> >We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation.

Does anyone have suggestions of some good code to read?

<comment><USER66> You'll probably have the best luck dissecting a program you're interested in.

</comment></comment><comment><USER67> That is particularly important in connection to management techniques. Programmers are not dumb automata.

</comment><comment><USER68> Exactly! Writing. Copyrightable but not patentable. :)

</comment><comment><USER69> "We should be immersing students in good code. We should be burying them in idiom after idiom after idiom, allowing them to acquire the ability to program without explanation."

^ bingo.

</comment><comment><USER70> ... and "code should read like prose".

this is an old idea.

</comment><comment><USER71> I think good writing is conversational in nature.

I don't think writing code works that way.

<comment><USER72> Way to take this conversational thread out of the analogy! Its an analogy that is instructional but clearly not applicable for all writing. I hope to never see code that looks like a Faulkner novel, for example.

</comment></comment><comment> Zeus-TheTrueGod I've read the article. I am sure that when a new child is born he has, say, a 5% chance to have an ability to be a programmer. After the lucky one grown up he will get all required information and experience just because he has the ability and finally, say in 10 years, will be a good programmer. Other 95% may do everything they want, they can learn how to program, read a lot of books, do all their homework and hobby project, but they will grow up only to the certain level.

I want to believe in what I've just wrote cause that guarantee that I will not have a lot of competitors and I'll always have a job when I want

</comment><comment><USER73> Programming is a compressed form of serial semantic thinking. It requires the same brain structures as math and language, so it's similar to writing, except it's more specialized and more restrictive. It's also very effective

</comment><comment><USER74> Of COURSE. Why would anyone think anything else?

For more, let's start with source code. Suppose we have source code line

         a = b*c

Reading this line, we want to know what it does and check that it's correct. So, we need to know what the line 'means'.

But, we conclude that

         a = b*c

doesn't really mean anything.

Of course if we saw

         F = m*a

we might guess that the variable names were mnemonic and guess Newton's second law that force equals mass times acceleration. Okay, now we know what the line means and can check if it's correct.

Okay, we are beginning to see:

A line of code such as

         a = b*c

doesn't mean anything. So, we have nothing to read and no way to check. So, we don't have anything.

We could write

         F = m*a

and begin to guess what this means. But we are still in trouble: We still have no good way to communicate meaning to permit understanding or checking.

So, we have to ask,

         F = m*a

came from physics books, and what did those books do? Well, they wrote in a natural language, say, English. Always, an equation such as

         F = m*a

was just an abbreviation of what was said in English. And, in particular, from the English there was no question about the meaning of each of the variables.

Net, math, and science with math, are written in complete sentences in a natural language. The variables are all clearly defined, discussed, explained, etc. At no time is an algebraic expression of such variables regarded as a substitute for the natural language. Take a physics book, throwout the English and leave just the equations, and will have nothing.

Physics and math understand; so far computing does not.

So computing tries to write

         force = mass*acceleration

or some such and omit the English. For simple things, can get by this way. Otherwise, this approach is hopeless, at best presents the reader a puzzle problem of guessing.

The matter of using mnemonic variable names as parts of speech in English is a grand mistake but common in writing in computer science. Bummer.

Bluntly computing has not figured out that there is so far just one way to communicate meaning: Use complete sentences in a natural language. Period. That's all we've got. But computing has fooled itself into believing that algebraic expressions with mnemonic variable names form a 'new language' that, in computer source code, can provide the needed meaning without a natural language. Wrong.

For

         F = m*a

the situation is simple. But significant source code has much more complicated cases of 'meaning' to communicate. Again, computing tries to get by, say, using a big library of software classes, relying the mnemonic spelling of the classes and members and the documentation of the classes. In simple cases, can get by this way. But fundamentally, for some complicated code, the meaning, workings, etc. just must be explained, and there's only one way to do this: Complete sentences.

So, writing these complete sentences to communicate meaning effectively is 'writing'.

Done!

</comment><comment><USER75> Wait, SlashDot is still around?</comment>


The House Always Wins - <AUTHOR> http://www.teslamotors.com/blog/house-always-wins <comment> swagasaurus-rex The responses Elon has previously written to criticisms have been very concise and convincing. This article isn't too far off the mark, but I do feel his frustration for the petty politics he deals with shows through the article.

Is it even necessary for him to respond to petty accusations such as the inflated claims that he's masterminding Nevada's politics? Wouldn't it benefit him more to let the nay-sayers nay say?

<comment><USER3> I agree. In the past the responses have always been to things that actually seem worth responding to (though there's plenty of disagreement about specific responses). In this case, I haven't seen any of these negative articles, so anecdotally, it seems perhaps not widely-reported enough to be worth a public blog post.

Furthermore, while I think describing why the deal is a good idea is reasonable, that whole lead-off with "haha they're gamblers, you think Tesla could pull a fast one on them?" is kind of strange. It's basically an appeal to authority, where the "authority" is people who oversee the gambling industry, and the claim is that because casinos are really good at not being tricked, then their overseers (i.e. the Nevada legislature) must be even better. Except it doesn't work like that, the casinos are not gambling with the state, or trying to pull a fast one on the state at all. And the Nevada legislature doesn't directly oversee the casinos anyway; they simply tax them. It's the Nevada Gaming Commission that does the actual regulation of the casinos.

Basically, that second paragraph is just a combination of multiple rhetorical fallacies intended to imply that it's preposterous to claim that Tesla could ever get the Nevada legislature to agree to a bad deal. And for any readers who recognize this, it only serves to weaken the rest of the blog post. If that entire paragraph (and the single word "Moreover" from the start of the next paragraph) were to be deleted from the post, the post would make just as much sense and would have a stronger, more focused point. And it would also make Elon look better by virtue of being willing to just state the facts and let them speak for themselves.

<comment><USER4> I think Elon Musk chooses a narrative for each post that supports the overarching image of Tesla and also couches the points he is going to make for public consumption. One major component of that is presenting an image to organize everything else around. "The House Always Wins" is a powerful one. Rhetoric involves more than just logos but also pathos and ethos.

</comment></comment></comment><comment><USER5> Called it, 2.5 months ago. Most of HN said I was wrong.

 _If the 1.25B tax break causes a net gain in tax receipts due to the expansion of the economy, then the deal is a net positive for everyone, job- seekers, Nevada, and Tesla.

No one loses when the economic pie gets bigger. Economics is not zero-sum._

[https://news.ycombinator.com/item?id=8271914](https://news.ycombinator.com/item?id=8271914)

<comment><USER6> I find this post crass.

gph's reply to you was reasonable, and you made no counter. It's a pretty obviously a difference of opinion (and politics), and reasonable points were made in either direction.

So now two months later, you paint a picture wherein you've been vindicated - using the proof that Elon Musk says that the deal Elon Musk made is good for everyone.

What was he going to say; the ink's dry on our signatures now, Nevada, so I can admit I totally screwed you over and there's nothing you can do about it? Come on.

Maybe you are right, maybe not, but no new information has come to light since the last discussion, and claiming victory based on a press release is intellectually dishonest.

<comment><USER5> As a general rule I don't participate in HN arguments, which is why I didn't reply to GPH. There is nothing I could have really added to the discussion and it would have simply devolved into a shouting match over which economic pet theories were HN's favorite. I am not really interested in shouting the loudest, it's a poor way to win arguments.

I am replying to you, because there is something I can add. My explanation of why I avoid replies. Take it as you want.

</comment></comment></comment><comment><USER7> > Our automotive plant in California has been in operation for over 60 years > with no foreseeable end in sight.

How can this be? Tesla Motors was founded in 2003. Did they take over the plant from some other manufacturer?

<comment><USER8> the plant was previously owned by General Motors and Toyota

<comment><USER9> More info for the curious:

The joint GM / Toyota project started in 1984: [http://en.wikipedia.org/wiki/NUMMI](http://en.wikipedia.org/wiki/NUMMI)

And the GM Fremont Assembly plant opened in 1962:

[http://en.wikipedia.org/wiki/Fremont_Assembly](http://en.wikipedia.org/wiki/Fremont_Assembly)

</comment></comment></comment><comment><USER10> Are the contracts open to the public? Between Tesla and Nevada?

</comment><comment><USER11> I don't know if the benefits were too large but Musk spends the entire article refuting something else: that the deal would be net negative to Nevada.

If I paid $1 for something and today's market price is $10 then I got a bad deal if I sell it for $5, even though I made a profit.

<comment><USER12> > If I paid $1 for something and today's market price is $10 then I got a bad > deal if I sell it for $5, even though I made a profit.

That depends on the circumstances. If you paid $1 for something, and someone else went in on the deal with you for 50% of the revenue if it went up but 100% of the loss if it failed, then selling it for $5 for you and $5 for the person shouldering the risk is not a bad deal for you at all.

<comment><USER11> It was a simple example used to illustrate that there are obvious situations where you get a bad deal even though you profit. You can also create other examples that do different things and aren't germane to that point.

</comment></comment></comment><comment><USER13> what is wrong with such deals is that one needs to be big (and/or extremely politically connected) to get one. I.e. the game is tilted. I mean why a small shop should pay higher taxes than a big one? How is that good for economy/society?

<comment><USER14> > _why a small shop should pay higher taxes than a big one?_

As long as money will buy political power, the little guy will always lose this game.

Get money out of politics if you want to change anything. Separation of Money and State.

<comment><USER15> You can not get money of politics if major part of politics is deciding who gets billions of money. If Nevada has power of taxation (and thus of tax breaks) and somebody comes and says "give me 1bn of tax breaks for next 20 years and I'll put $lots_of_money of new taxable income in your state budget, and that wouldn't cost you anything to current budget" their voice would be heard by Nevada politicians much louder than a voice of somebody whose yearly revenue doesn't break into six figures. As long as the politicians have their hands in the economy (and they do quite a lot) it would be negligent for them not to listen to major economic movers. It's their (budget) money that are on stake, of course they'd listen.

</comment></comment></comment><comment><USER16> I had never read much Elon Musk before but I am incredibly impressed with his Elon Musk's eloquent Elon Musk is. This deal is undoubtedly good for Nevada. These tax incentives always seem to me to be a zero sum game. They benefit large corporations who have the ability to negotiate with states at the expense of smaller corporations who do not have that ability. In essence they cause small corporations, or individuals to subsidize large corporations.

</comment><comment><USER17> These deals are net positive for Nevada (tax breaks don't really hurt them that much if they wouldn't have gotten the facility anyway), and net negative for the US overall (revenue wise, at least). If nobody engaged in these kinds of deals then Tesla would surely pay more tax.

I don't blame Nevada for engaging in it, and I think they probably won overall.

Other factors (cheap land, regulatory, etc) almost definitely came into play but nobody is really complaining about those.

<comment><USER15> It's hard to say if Tesla paid more tax, as Tesla might not build the factory at all, or could build it in other country. The thing is there's nothing sacred in current level of taxation, so I personally consider tax breaks the least evil form of subsidizing, especially if the tax is not a purpose tax for shared resource (e.g., if there's a property tax to finance common school and somebody uses the school but doesn't pay the tax, all others pay more) but a tax break on indefinite further earnings which may not have happened without the tax break. Yes, it looks like crony capitalism and sometimes it is, but if the opportunity cost is low (i.e., nothing really was being built there otherwise) then I don't see why Nevada shouldn't do it.

</comment></comment><comment><USER18> Seems to me like their competition must have been busy trying to smear them, it is much easier to smear someone than clear ones name.

</comment><comment><USER19> I realize this is off topic, but I take serious issue with the statement that "Nevada is the entertainment capital of the world."

<comment><USER20> What would you say is the entertainment capital of the world? I live in Los Angeles, and at one time in the past I would have associated this city with entertainment. But it's been many years since our business climate was especially amenable to film and television production; now much of what we used to do here is done out of state, in Canada, or overseas.

<comment><USER21> I suppose it depends on how you'd even define something like that - headquarters, production, shooting, effects.. it's all so distributed now. Consider SohoNet's reach, as a network provider that specialises in high capacity connections to studios, effects houses, et al:

[http://www.sohonet.com/our-global-reach/](http://www.sohonet.com/our-global- reach/)

That said, I'd wager you could ask people around the world, and they'd still say "Hollywood", though plenty of folk are, I'd imagine, aware of Vancouver's popularity for doubling as many US cities, Pinewood Studios, and WETA.

</comment></comment></comment><comment><USER22> Bullshit. There are always externalities in these deals. Since I do not know the details, I can.not say. But what about things like pollusion and waste. These are negatives to the people of nevada that are most likely not accounted for. Also work olace hazards ir worse damage, explosions, etc.

Also what about surrounding infrastructure like roads, sewage, etc. Who is paying for that?

<comment><USER23> Your argument is that all deals governments make are bad, this is a deal, so it must be bad?

<comment><USER24> I would argue that they are. States competing on deals like this is bad. If no state gave an incentive, they'd have to pick one at full price anyway. Also, if the deal is good with Tesla, why not give similar deals to every company that wants to put up a building? In the end states will just forego corporate taxes altogether and get all their revenue from the people. Is that bad? I'd have to think harder before answering that, but I'm inclined to say yes. Corporations don't retire, people do. People need to be able to get of the monetary treadmill, but companies don't.

<comment><USER15> >> If no state gave an incentive, they'd have to pick one at full price anyway

Or build it in another country and people could scream at them for being unpatriotic.

>> Also, if the deal is good with Tesla, why not give similar deals to every company that wants to put up a building?

You are arguing for lower taxes. This is a noble goal, but much harder to achieve than such deal. As Bismarck said, politics is the art of the possible. It's not ideal, but given current situation it's also not the worst outcome.

>> In the end states will just forego corporate taxes altogether and get all their revenue from the people.

Corporate taxes are about 10% of budget income, despite US corporate tax rates being one of the highest in the world. So it's neither unprecedented not unimaginable to have lower corporate tax rates. As for the people, corporations are ultimately owned by people, so it's still tax on people, just certain kind of people - doing business in the US. Every dollar taken as corporate tax is not paid as dividend, not invested in hiring another worker, not spent on buying supplies or services. So ultimately it's people all the way down.

<comment><USER24> >> Every dollar taken as corporate tax is not paid as dividend, not invested in hiring another worker, not spent on buying supplies or services.

Sure it is, just not spent by the corporation. The government will spend it - they can't seem to help themselves. The only thing taxes change is who gets to control where the money goes.

One can just as easily say "tax corporate revenue" and not paychecks, since it's allegedly circular with money going back and forth between people and companies (people all the way down). I'm not advocating this of course, but we're living in a time when your assertions about profit going to hiring, supplies, and services are clearly false. It happens, but it's certainly not a given.

<comment><USER15> We were talking about the revenues - the idea was that all tax revenue ultimately comes "from people", every economic decision affects people - because people are the only willful agents in the economy, there's nobody else.

>>> The only thing taxes change is who gets to control where the money goes.

Not entirely. The government usually proves to have quite inefficient with how it spends revenues. Sometimes it is necessary - i.e., feeding the destitute produces no money, but has a humanitarian value. Sometimes, it is not - <USER2> spending billions on bridges to nowhere and crony projects that collapse the minute government financing is withdrawn. So we also have to consider the destruction of value that the government involvement usually brings about. Of course, corporations can destroy value too - but usually can't survive for very long once they started to do it unless they manage to stop. For the government, it has to be extraordinarily destructive to collapse, for a company, the bar is much lower.

>>> your assertions about profit going to hiring, supplies, and services are clearly false. It happens, but it's certainly not a given.

Err, I'm not sure where your "clearly false" comes from. Is it clear to you that corporations do not spend money on hiring, supplies and services? How they then manage to have people show up to work and suppliers to give them supplies and services, if they don't pay for it? Also, if some fairyland corporation ever managed to pull off such impossible trick, it still wouldn't change a thing, as that would only mean entire revenue goes to the corporation owners - i.e., again, "people".</comment></comment></comment></comment></comment></comment>


Chip company unveils new open-source PC design - <AUTHOR> http://www.wired.com/gadgets/pcs/news/2008/05/via_design

<comment><USER2> I registered at viaopenbook, but when I tried to log in, I got an alert that read "Your login has been blocked. Contact the administrator."

What?

</comment><comment><USER3> Now if only someone would unveil an open-source CAD program that didn't hark back to the 80s...</comment>