Is 'Oumuamua an alien spacecraft? First scans show no signs of technology - <AUTHOR> https://www.theguardian.com/science/2017/dec/14/is-oumuamua-an-alien-spacecraft-first-scans-show-no-signs-of-technology <comment><USER2> Okay, so it's a stealth ship:

[http://toughsf.blogspot.com/2016/10/the-hydrogen-steamer- ste...](http://toughsf.blogspot.com/2016/10/the-hydrogen-steamer-stealth- spaceship.html)

</comment><comment><USER3> I'm kind of glad to hear that to be honest. It's already too far away from us and going too fast for any spacecraft that could currently be built to reach it. It would have been a very cruel joke if the first opportunity for interaction with extra terrestrial intelligence flew past us so unceremoniously.

Of course it's certainly disappointing that it isn't an alien spacecraft, but would have been doubly so if it were and we missed our window of opportunity.

<comment><USER4> I dunno I think if it were an alien spacecraft we should just keep our heads low and not draw any attention to it. Our first window of opportunity might be our last.

<comment><USER3> I've gotta disagree with you on this. Personally I think intelligent life is probably very rare in the universe, the sheer number of factors that need to go right for it to arise, and then the sheer number of factors that need to _not_ go wrong for it to continue to exist mean any intelligent life out there is probably going to find us way more valuable and worthy of co-operation and interaction than say destruction of us for the measly resources of Earth, or enslavement (although I guess enslavement could be possible).

I do also have faith in the "humanity" of any interstellar life that may exist out there, after all a society based on oppression tends to be rife with conflict, and societies rife with instability and conflict don't tend to last. And in my view it would be very unsustainable for any life to maintain that sort of conflict, and at the same time hope to extend a society out into the universe.

Nothing ventured, nothing gained. I think it's worth the risk.

<comment><USER5> What if intelligent life is rare because at some point some other intelligent life set up a systematic process of keeping the universe clear of it?

<comment><USER6> You've been playing too much Mass Effect 2 :^)

<comment><USER5> I've actually never played any Mass Effect...

</comment></comment></comment></comment></comment></comment><comment><USER7> They mentioned that they're scanning a frequency range from 1 to 12 GHz.

Why that range? And what if it's transmitting at 0.5 or 13 GHz, or 500 GHz? Would that show up, just weaker or..?

<comment><USER8> As a radio-astronomer: 1\. Well, few radio-telescopes have instantaneous bandwidth as wide as a factor of 12 -- they are usually optimal on a narrow region, and therefore hoping that another group with instruments optimized for lower/higher frequencies will do the job 2\. Lower frequencies require larger antennas to achieve useful gain. It is more likely that they would go higher than 500 MHz vs lower. Also, dispersion (correctable with a position solve) and scattering (not correctable) eventually become problems with low enough frequencies and long enough distances 3\. If we observe at the wrong frequencies, it will most likely not show up. RF filtering and antenna response will ensure that.

</comment></comment><comment><USER9> What if it's shields are up?

</comment><comment><USER10> "Plane change maneuvers are expensive"

<comment><USER11> I wish that book had a better ending.

<comment><USER12> Which book is that?

<comment><USER13> Seveneves, if I'm reading the OP correctly. By Neal Stephenson.

</comment></comment></comment></comment><comment><USER14> First thing what I do if it is my spacecraft i will not send anything until I'll far away enough to not be detected and probably won't point transmitter to planet which are investigated (I know that signal can be reflected back from cosmic debris, but who can send rock to other solar system won't have problem to calculate signal path which doesn't point to us)

</comment><comment><USER15> Maybe it's the interstellar equivalent of throwing a rock at someone's window to get their attention? An alien race could have used a gravitational slingshot to send it our way.

</comment><comment><USER16> Obviously, this indicates they're using technology far exceeding ours that's undetectable to our sensors.

<comment><AUTHOR> It could also be just a dead spacecraft, than was once operational but is no longer so. That could also be why it's tumbling now, whereas once it may have flown in a more aerodynamic fashion.

<comment><USER17> it's obvious what you're describing but just wanted to point out that aerodynamic is a poor choice of words to describe an interstellar body :)

<comment><USER18> If it's tumbling to provide artificial gravity, then the crew needs something like 8.94595e-7 g to feel comfortable.

</comment></comment></comment></comment><comment><USER19> Coming up next on the History Channel: Preliminary scans indicated 'Oumuamua was just a lump of space rock. But could it be... a _derelict_ alien spaceship?

<comment><USER20> Perhaps like the _derelict_ spacecraft discovered in Alien[1]. Check for a warning signal!

[1] [http://alienanthology.wikia.com/wiki/The_Derelict](http://alienanthology.wikia.com/wiki/The_Derelict)

<comment><USER19> Or perhaps it's like the _Macross_ , so completely inert -- but set to go off once the Zentraedi come around to investigate.

</comment></comment></comment><comment><USER21> The article makes a much more limited claim than what the headline suggests:

"the search for alien signals has so far found nothing in the 1.7 to 2.6GHz range"

Scanning continues.

</comment><comment><USER22> > The cigar-shaped object ...

All they have is a light curve, right? No imaging, right?

If so, "cigar-shaped" is just speculation.

<comment><USER23> It rotates, so its brightness changes over time. From examining this data they can draw some conclusions about its shape.

<comment><USER22> Sure, but "some conclusions" is a long way from "cigar-shaped".

<comment><USER23> When a factual mistake is called out, it's probably better to do some research instead of doubling down.

>The astronomers figured out its elongated shape when they noticed its brightness varied when it rotated every 7.3 hours. When the asteroid's long side faced the Earth, more of its surface area could reflect sunlight, making it more visible to us. And when the tip of the rock faced us, it was a very dim point of light.

>"What we found was a rapidly rotating object, at least the size of a football field, that changed in brightness quite dramatically," planetary astronomer Karen Meech, who led the University of Hawaii team, said in a statement. "This change in brightness hints that 'Oumuamua could be more than 10 times longer than it is wide — something that has never been seen in our own solar system."

Source: [https://www.pbs.org/newshour/science/a-cigar-shaped- asteroid...](https://www.pbs.org/newshour/science/a-cigar-shaped-asteroid- just-boomeranged-through-our-solar-system)

Statement from the team in Hawaii: [http://www.ifa.hawaii.edu/info/press- releases/Oumuamua/](http://www.ifa.hawaii.edu/info/press-releases/Oumuamua/)

You would be surprised how much we can infer with p>0.05 based on information that looks scarce from the outside. Much of what we know about the universe is found from surprisingly simple sources.

<comment><USER22> We'll never know.

</comment></comment></comment></comment></comment><comment><USER24> Maybe it's just one stage of a rocket that is slowing down?

</comment><comment><USER25> Any headline with a question mark can be answered: no

<comment><USER25> [https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)

</comment></comment><comment><USER26> it is on scout mission, invasion is now imminent

</comment><comment><USER27> take me now. this world is too crazy for me. :(

</comment><comment><USER28> ego blow, we're not even probe worth

</comment><comment><USER29> There's only one apostrophe in the name. It's not quote marks. [https://en.wikipedia.org/wiki/ʻOumuamua](https://en.wikipedia.org/wiki/ʻOumuamua) Or to be really specific [https://www.fileformat.info/info/unicode/char/02bb/index.htm](https://www.fileformat.info/info/unicode/char/02bb/index.htm) "typographical alternate for U+02BD or U+02BF used in Hawai`ian orthography as `okina (glottal stop)"</comment>


Golden rules for becoming a better programmer - <AUTHOR> http://www.codeshare.co.uk/blog/10-golden-rules-for-becoming-a-better-programmer/ <comment><USER3> Ten low-level, generic advices. Too low level to do any good in larger picture, and too generic to be applicable in real life as-is. The only exception is not interrupting people when they are in the middle of work.

There are several high-level advices that are similarly generic: break up your program to subsystems of clearly defined interface and purpose, make the subsystems composable by not loading them with too many purposes, don't mix high-level and low-level purposes or operations in the same interface, avoid putting dependencies on other modules or services unless necessary, and know which operation belongs to which module. _Those_ make good programmer, not minutiae about creating identifiers.

<comment><USER4> I like to generalize it to "Understand and consistently apply the concepts and good practices of your chosen field".

This requires you to find out what good practices are, understanding why they are good practices and then working on making them a habit so they reliably show up in your work.

The issue I have with the article myself is that it over-promises in the title and under-delivers in the body.

The rules are drawn at random from things that make good sense, with no attention to order in level, area, or importance. DRY is a pattern, not commenting code is an anti-pattern, and not interrupting co-workers is workplace etiquette. Some rules are obvious to the intermediate [DRY, no magic numbers], whilst others are confusing to the beginner [eliminating dependencies to make code easier to test]. This makes the list useful for neither.

Calling this "golden rules" seems dishonest. "My rules for becoming a better programmer" would be a more accurate, albeit more boring title.

<comment><USER5> Yeah, this article reads like someone was forced by their employer to write a blog post. If it was for self-promotion you'd think they'd put a bit more effort into it. Would be better if retitled to "10 things that just so happened to pop into my head".

</comment></comment></comment><comment><USER6> 11\. Know when to break any of the first 10 rules.

12\. Never listen to anybody who tells you "You shouldn't need comments if your code is clear enough to read." \- the next one reading your code (probably you, 10 years later) will love you for documenting the WHY just as much as s/he'll hate you for having to rely on documentation that explains the WHAT.

<comment><USER7> I like how Robert C. Martin puts it: before you write a comment, ask yourself whether you can write the code in a way that makes the comment unnecessary. If you cannot, then it is better to leave the comment than none at all.

<comment><USER8> Fair enough, so long as you understand that programming languages are not expressive enough, in general, to clearly explain purpose and rationale. In these matters, providing a hint through identifier naming is not an adequate substitute for a clear explanation in a human language.

</comment></comment></comment><comment><USER9> Some of these could serve as philosophical starting points but are a bit too dogmatic for "rules".

1\. DRY

I like the Rule of Three better, and even that is flexible. It's important to find an underlying abstraction and not just extract common chunks of code because they happen to be similar.

4\. No literals

Eh, not really. Most of the time I'd rather just see the value and not have to follow a reference to the definition of a constant.

5\. Avoid dependencies

Yeah, probably true for application level settings like he describes, but don't go crazy with it. The goal is to have clean readable code and tests. Its just a headache when everything is a FooImpl of a FooInterface, for instance, and not really a win for testability.

<comment><USER10> > 4\. No literals

Generally I agree with you here, but I _think_ what the post is getting at is more the one case where you do want a variable in place of a literal - <USER2> passing the literal into a function where its purpose isn't immediately obvious. Passing the literal behind a more meaningful variable name can provide cleaner, self-documenting code in cases where, for example, modifying the function isn't possible and writing an adaptor would be overkill.

<comment><USER11> The second-most egregious pattern I see at work:

      const char* kEmpty = "";

Makes me want to poke my eyes out with a stick everytime I see _kEmpty_ used..

(The most egregious thing is spaces inside parens. But that's just a personal preference. In general I tend to be quite _laissez-faire_ about tolerating different styles, and consider style guides to be a pox because they tend to give the subliminal message that your code is done when it complies with the style guide.)

<comment><USER10> I'm 100% with you, the variable name _kEmpty_ here is completely tautological - it just describes the literal in a different, clunkier way, and doesn't add any information. Kind of similar to something like _nameOfSteve = "steve"_

The case where it's useful is where instead you'd call the variable referring to a constant something like _dollarCurrencyCode = "USD"_, where you have to use an api which takes a currency code but you will always pass "USD". To the uninitiated reader, what purpose does the literal "USD" serve - what does it _mean_? It's not clear, because they don't know the api, and may not intuit currency codes. Putting it behind the _dollarCurrencyCode_ variable name makes it a lot clearer on first glance. If they care to know what the dollarCurrencyCode is 'under the hood', they can then look, but this is a lower level detail of the underlying api and doesn't help with understanding.

</comment></comment></comment></comment><comment><USER12> The boy scout rule does not apply to programming. Please don't do this.

Found a bug? Fix it and add a test for it. Don't "tidy up" what you consider a "mess".

<comment><USER13> I couldn't agree more. This a sure path to disaster and unhappiness. Fixing code requires understanding what it is doing in all except the most basic examples.

Unless you have a firm set of tests, or strict API constraints defined, don't ever follow this rule. It will only lead to a sad tail of how you created this huge bug that deleted all the customers data because you though this Boolean wasn't used anymore, so you removed it. It makes for a funny story, but a really bad couple of weeks.

<comment><USER14> Worst case, as you said, but the best case is...nothing. You're literally spending a bunch of time doing a high risk activity to produce nothing of value. It might be easier to read, but if the original developer is long gone, then it's likely nobody will look at it again for years (unless you broke something and the next guy rolls back your changes in VCS).

Taking on a foolish refactoring project is a rite of passage for developers.

</comment></comment></comment><comment><USER15> This is the type of article that spawns the best and most informative comments. As a rather isolated programmer being able to browse through the HN comment section and read everyone's different perspective of "rules for becoming a better programmer", I find is infinitely more constructive than reading blog posts. It also somehow feels more credible... So thanks I suppose.

</comment><comment><USER16> Disagree _strongly_ with the "boy-scout rule". If it's a bug, then fix it, but if it's messy code, then _leave it_! There's no reason to touch something that may be working fine and for you to create subtle bugs.

<comment><USER17> If you have the _option_ of leaving it alone, then you probably should, however if you've already got to work on the messy part anyway, and if the code is messy to the point of being difficult to read, then you might be _reducing_ the chance of introducing new bugs if the first thing you do is refactor the lot such that you don't cringe just looking at it.

I'm talking about cleaning up _the code_ though, not the _logic_ \- refactor really isn't even the right word. Poor choices for variable names, misleading or just plain wrong comments, inconsistent use of whitespace, etc etc.

And even this you should only do if you really think it's necessary, since it will make it very difficult to use diff to suss out what your _actual_ changes to the area were after you're done. Still, there is a time and a place for it.

<comment><USER18> If you use your VCS right the diff issue doesn't have to be a problem. Do the tidying up in the upstream branch, or at least as a separate commit that can precedes your actual logic changes.

</comment></comment></comment><comment><USER19> I would add: Also research tools/concepts that you can't understand yet, and read programming books above your level.

Because after enough time your brain will have collected enough information to understand them ( _I call it the 'click' \-- that moment where everything clicks and becomes clearer_), and you will become a better programmer because of it.

<comment><USER20> Agreed. Everyone loves gof design patterns, but the real gems for practitioners start a couple level below in abstraction: code complete basically shortcuts you five years of experience and Fowler refactoring + patterns of ea ground yourself in making what it's needed and not what it's dreamed

</comment></comment><comment><USER21> It's been my experience that clever architecture tends to beat clever coding and tactics.

I don't think I started to have an idea of what being a better programmer was, until I had a relationship with multiple code bases that I had started or built and were 5-7 years old.

What came from it?

\- idea of being kind to your future self,

\- coding in a way that the next person could quickly pick up on it vs building a tribute to my own cleverness

\- not prematurely optimizing

\- refactoring being expected

\- learning to solve all sorts of small and not-small problems

\- being open to the idea that few problems haven't been thought about or solved already

</comment><comment><USER22> The article's advice is rather generic, though it did bring up some interesting responses. The rule about comments in code elicited a minor controversy, but I tend to agree with the sentiment that adding comments is more worthwhile than not.

The program logic may be clear to the author but there's a good chance it won't be to others using it, especially when 6 months later I'm one of those "others". At that point it's usually easier to determine if a comment really clarifies things and if not remove or modify it.

I'm surprised not much said here about rule 10. Giving feedback to team members is an essential part of teamwork, e.g., certainly it can't work if problems with code aren't expressed. However I think what the author is getting at is the fine line between "criticism" and "critique", the latter meaning communication re: mistakes, etc., in a constructive, generous and objective way.

Without due care in expression, teams risk degenerating into factions arguing over who's "right", who's to blame, and there progress grinds to a halt. It's always obvious when other teams are in this state, but frequently we don't see it in ourselves or happening in our own group. Mastering the art of critique, including self-critique, is hard, but an amazingly valuable skill to learn.

</comment><comment> mark-r I have 2 rules:

1\. Practice, practice, practice. This goes for any endeavor in life, not just programming - the more you do it, the better you get.

2\. Never settle for your first attempt, always be thinking of ways to improve. Sometimes I'll come up with ways to redo something years after the opportunity to do so has passed, just because it's still on my mind. Hopefully when a similar situation presents itself the better method will be my first choice.

</comment><comment><USER23> a golden rule for golden rules: show concrete examples if you really want to communicate what you mean

<comment><USER15> Agreed, this blog post is very buzzfeedesque and must have taken an hour or less to bang out... surprised its that high up on the feed.

</comment></comment><comment><USER24> 11\. Take occasional breaks. Yes its sometimes a good idea to get out of the zone.

I can't tell you how many times I have written a 500 or so lines of code and realized after taking a break I was going down the wrong path or was thinking about the problem incorrectly.

</comment><comment><USER20> Like Spencers' ten commanments except with calls to unspecified external practices, less funny and ultimately not really actually for programmers

</comment><comment><AUTHOR> You shouldn't need many comments if your code is clearly written and named. Just a summary above each method.

<comment><USER9> Nope. In my career I've never seen this mythical code that doesn't need comments. Tell me about preconditions, postconditions, performance characteristics, quirks, absolutely anything and everything that could affect the caller.

<comment><USER25> I've often seen assertions like this that all / most code requires comments. I hold a personal view that it's actually the opposite, but can't seem to get anyone above to bite and show me useful real code provides a counterpoint to my view.

Can you point to an open source repo somewhere that demonstrates your point that comments are preferable to writing clear code without comments?

I'm sure you can point to repos where poorly written code requires comments in order to be properly explained. This is not really what I'm after, as I'd contend it's likely that writing the code better would be more useful to that project.</comment></comment></comment>


"Add Analytics" is a Terrible Requirement - <AUTHOR> http://designbyrobots.com/2011/01/31/add-analytics-is-a-terrible-requirement/

<comment><USER2> It's not really a requirement, any more than "Add a user interface" would be a requirement. It describes a perceived need (which could be real or marketing created) that ought to be broken down into specific requirements.

Most people/companies don't have any idea what can be done with their data or how it would help their business, and as such, aren't in the position to formulate clear requirements. Saying "I want to add analytics" is just shorthand for "I've got a lot of data, some of which I suspect could be valuable and want to start doing something with it."</comment>


So You Want to Write Your Own Language (2014) - <AUTHOR> http://www.drdobbs.com/architecture-and-design/so-you-want-to-write-your-own-language/240165488 <comment><USER2> I've always found it unfortunate how he, and others, implicitly define the _success_ of a programming language as its _popularity_. A programming language can be incredibly interesting and useful to you and others without ever becoming fashionable—and that doesn't mean it has failed!

I think there should be other metrics for success: a programming language can be useful _to a dedicated community of experts_ , it can be useful _to a single company_ , it can be great _for a single use-case_ or even just great _for you_ , it can push _novel ideas_ or showcase a _novel design philosophy_ , all without massive popularity or market success. (And it's not like most languages directly make lots of money anyhow.)

Popularity is a poor proxy for quality, and quality matters all on its own.

Keeping this in mind changes a lot of his suggestions, I think.

Completely unrelated note: what the article calls "lowering" I've more commonly seen called "desugaring" and is, indeed, a powerful technique both in terms of _implementation_ but also in terms of _understanding_ a language—if a piece of syntax is pure sugar, you don't have to understand anything new, just how the syntax it desugars to works.

<comment><USER3> FWIW, I have more often seen the term "lowering" used by people who do research in this field and "desugaring" mostly among industry developers.

<comment><USER2> Most of the time I see desugaring _is_ in a research context, at least within areas of PL adjacent to functional programming.

</comment></comment></comment><comment><USER4> I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for programmers to understand. In short, I'd rather have Scheme than Ruby. But I seem to be in the minority...

<comment><USER5> Easy (for a computer) to parse does not necessarily mean simpler for programmers to understand. I think Lisp's deeply nested parens are a good example of this problem.

<comment><USER6> J is also quite easy to parse, but could be difficult to understand. (See e.g. [http://sblom.github.io/openj- core/iojSent.htm#Parsing](http://sblom.github.io/openj- core/iojSent.htm#Parsing))

<comment><USER7> J is one of my favorites. The syntax is cryptic at first, but the lack of ambiguity makes programs easier to understand and easier to design in the long run.

<comment><USER8> I dunno, I think proper anonymous functions would have been a lot better than hooks and forks.

Though I'm not sure if that falls under syntax or semantics for purposes of this discussion.

</comment></comment></comment></comment></comment><comment><USER9> It's a decent list but not enough. The real trick is being general purpose enough to handle low-level up to programming in the large while being comprehensible and easy for compiler to work with. In my field, highly-assured INFOSEC, you also want correctness and traceability for security purposes.

I wrote an essay on a layered, bottom-up approach to constructing such a language here if anyone is interested:

[https://www.schneier.com/blog/archives/2014/05/friday_squid_...](https://www.schneier.com/blog/archives/2014/05/friday_squid_bl_423.html#c5828584)

I'm also interested in feedback on my approach. It tries to solve probably a dozen problems at once with some basic principles and three, compatible languages.

<comment><USER10> I'm not sure I understand the value of having tools to "downgrade" something to a lower level. I compare this "downgrading" with "compiling to C" \- a feature that enables some languages to become useful on more than one platform just by riding on the back of the C language. Was it about this idea of having different layers so that one may care to really port only the lowest level when it comes to it? But then the scope you get on the lower levels is simply inferior compared to the one you get on higher level/layer in terms of optimization possibilities, partly because you are now forced to get from point A (source code) to point B (binary code) not directly but through a 3rd point - C (a lower level source code), which may hurt performance and other things. Did I misunderstood something?

<comment><USER9> It's an exploration so I was throwing "downgrading" out there. You almost guessed it all with portability and bringing on new programmers. Both arguments for that technique. Another, esp if compiler is written in an ML, is that code used to analyze, optimize, or translate lower layers of language can be re-used in compiler for high-level.

Matter of fact, I think my default was to go to ASM with plugins for other stuff. That should prevent missed opportunities in optimization.

</comment></comment></comment><comment><USER11> Minimizing key strokes is seen as 'false', but it has actually been proven that one can write (debug, maintain,...) about 10 lines of code per hour. Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of haskell. Of course, you can do much more in 10 lines of haskell than you can do in 10 lines of assembly. It basically means you want to be work on the highest level of abstraction that you can afford. It also means that economy of expression is important. source: [https://vimeo.com/9270320](https://vimeo.com/9270320)

<comment><USER12> > Those 10 lines can be 10 lines of assembly, 10 lines of c++ or 10 lines of > haskell.

I seriously doubt the validity of this. 10 lines of assembly is usually reasonably clear-cut what is about.

10 lines of Haskell can take hours of mindfuck trying to peer through the functor and monad operators, trying to work out which operation does what and which operator takes precedence where. And then you need to start worrying about which data-type are you _actually_ working on. And how does that type implement lift and bind. Etc etc.

Basically 10 seems like a BS number taken out of thin air, because it looks good in a base 0x0a number-system.

<comment><USER13> > 10 lines of Haskell can take hours of mindfuck trying to peer through the > functor and monad operators,

Please stop. Can you even come up with one example that supports this? Alright, now how about 10 lines from a "real world"* Haskell project.

*real world meaning has at least 1 user besides it's developer

<comment><USER3> I think the more important counter-argument is "that ten lines of assembly just barely did one thing; the ten lines of Haskell was most of the program: clearly it will be easier for you to understand a single wire or switch than to understand an entire computer, but that isn't a valuable insight".

<comment><USER13> Hyperbole (if that is what the commenter was using and didn't seriously think it) should be used carefully when it reinforces stereotypes that are so damaging.

</comment></comment></comment></comment></comment><comment><USER14> For my project, I found sticking to LALR(1) quite beneficial. Not that there's anything special about LALR(1): you could use LL(k) instead if you prefer. However, by sticking to a small, deterministic syntax (and making the parser generator complain loudly in case of ambiguity), I can easily find edge cases I've never thought about before it comes around to bite me. And, in most cases, it's trivial to slightly modify the syntax so that the undesirable ambiguity does not arise.

It's the equivalent of static typing for syntax: it takes effort to make bison run successfully, but when it does, I know that my grammar is free of ambiguity.

</comment><comment><USER15> > Regex is just the wrong tool for lexing and parsing

Funny; I recently wrote an Island parser that extends Regex to create a token stream: [https://github.com/musesum/Par](https://github.com/musesum/Par)

Quoting the link to Rob Pike's post:

> Consider finding alphanumeric identifiers. It's not too hard to write the > regexp (something like "[a-ZA-Z_][a-ZA-Z_0-9]*"), but really not much harder > to write as a simple loop

Maybe I'm missing something, but does this suggest replacing a declaration with a procedure? Oh the horror!

</comment><comment><USER16> I disagree with several of these. But I guess that's why 1) I am working on my own language, and 2) Walter Bright is a lot more successful at that than me. So yeah. He's probably right, and I'm probably wrong. However: I'm doing this entirely for my own pleasure, and I don't want success as he defines it (popularity means having to cater to the whims of others).

Disagreements:

I think minimizing keystrokes _is_ important, and I think the notion that code is primarily read, not written, is idealistic but completely wrong. The purpose of programming languages is to be writable by humans and readable by machines. There is value in making them readable by humans and writable by machines, but only secondary value.

I think there is value in easy parsing, if nothing else because every single editor out there can highlight your language even if it isn't popular. I think the focus on popularity as the measure of success is wrong.

Tried and true is overrated. There are plenty of examples of programming languages that break the tried and true rules and are successful either because of this or despite this. Either way, it doesn't seem to matter as much as people seem to think, but staring too hard at the success of Java might make you think it does.

Anyway, feel free to disagree with me, go ahead and design your own language. I sincerely hope you are successful, regardless of what your definition of success is.

<comment><USER17> In practice, writing code consists mostly of reading; either to (re)understand how some other part of a large system works, or to figure out why the code is incorrect.

<comment><USER18> I would argue that it's easier to understand short, even excessively terse, code than it is to understand long code. I can look at a few lines of Haskell and even though deciphering it may take me some time, the cognitive overhead of anything other than working out what the code is doing is very low (the most I'd have to do is look up some operators). I can see a significant chunk of logic all at once and piece together the system as a whole. Meanwhile I could look at 3 files full of Java and have no idea what the system is actually doing.

</comment></comment></comment><comment><USER19>
      LinuxWorld.com: What is your advice to designers of new programming languages?

      Dennis Ritchie: At least for the people who send me mail about a new language
      that they're designing, the general advice is: do it to learn about how to
      write a compiler. Don't have any expectations that anyone will use it, unless
      you hook up with some sort of organization in a position to push it hard.
      It's a lottery, and some can buy a lot of the tickets. There are plenty of
      beautiful languages (more beautiful than C) that didn't catch on. But someone
      does win the lottery, and doing a language at least teaches you something.

      Oh, by the way, if your new language does begin to grow in usage, it can
      become really hard to fix early mistakes.[0]

[0] [http://www.itworld.com/article/2826125/development/the- futur...](http://www.itworld.com/article/2826125/development/the-future- according-to-dennis-ritchie--a-2000-interview-.html?page=2)

</comment><comment><USER20> > My career has been all about designing programming languages and writing > compilers for them.

Anyone knows which languages/compilers the author has worked on?

(I'm not trying to validate its arguments, it's just out of curiousity)

<comment><USER21> Digital Mars C, C++ and D compilers

<comment><USER22> To add more context to that [https://en.wikipedia.org/wiki/Walter_Bright](https://en.wikipedia.org/wiki/Walter_Bright)

Although i have never though of actually write a language i can agree on those. Especially Minimizing keystrokes. I want the language to be verbose and easy to understand. Dealing with thousands of line trying to figure out what is going on there it is essential to easily pick up what is going on !

<comment><USER23> > I want the language to be verbose and easy to understand.

So, you basically want to write in assembler, which printed is very verbose, and it's very easy to understand each separate instruction.

What I want is the language to minimize language entities used to do a task (from parser's perspective those would be AST nodes), and I want those tasks to be general and high-level. _This_ is what makes source code comprehensible, not verbosity.

<comment><USER24> Each instruction may be easy to understand, but the programs are not easy to understand at scale. So that's probably not what stevoo wants.

<comment><USER23> Of course it's not (or rather, I would be surprised if it was), but he phrased it in very wrong way.

</comment></comment></comment></comment></comment></comment><comment><USER25> My own opinion about PL research is that programming is _concept serialisation_ : the programmer has a model of the system (or part thereof) in their head, and the role of the language is to turn that into a byte sequence that is amenable to both being turned into machine instructions and being de- serialised into the heads of other programmers.

But different programmers have different abstractions in their heads, and find different things intuitive. That's why things like ColorForth and APL exist; to a tiny fraction of people and problem sets they're intuitive, to the rest obtuse. I suspect this is why people keep thinking Lisp is going to take over the world despite 30+ years of this not happening.

</comment><comment><USER26> _One thing abundantly clear is that syntax matters._

I feel this is like reading 100 years ago about how to make your own new type of horse & buggy, with tips like "make sure the reigns are well-fitted," when what you want to invent is a car.

The future doesn't belong to syntax because the future isn't text. The same people that would blanch at sending a string argument of "ONE" or "TWO" are indifferent about the fact that they send in "IF" to start a condition.

The reason you wouldn't send in "ONE" or "TWO" is because it makes it stiffer, more brittle and harder to manage. What can we say about the software we write? That it's stiff, brittle and hard to manage.

It's not that the future has no textual syntax at all, of course. An expression of 3+4*5 will always be easiest to express just that way. But we need to pull back from our gregarious, wide-mouthed babbling into something more meta, or I should say, more data, than text.

<comment><USER27> This is the ??? (I don't know what to describe it as) post here. You took the one sentence I just loved from the article and pooped on it. Then tried to tie it in with details of a non syntax related item and process. Next, you said a two character syntax for describing something as complex as an if statement was somehow too much burden?!

Not sure what the future of programming languages is. But if humans are involved I suspect there will be a visual representation. And that means syntax. And that syntax will matter then just as it does now.

<comment><USER26> I didn't mean to hurt your feelings. This is my opinion; I didn't expect it to receive a warm reception.

If you went to a horse and buggy convention 150 years ago and told them that it would all be gone soon, they would have virulent reaction, right? They would say that metal contraptions have been tried before and failed, that humans have been using horses for travel for thousands of years and if so if humans are involved, it will mean horses. This isn't to prove my point but to draw caution to yours.

Note that I understand your position quite well but that you clearly don't remotely understand anything that I've written. That should raise a flag. Instead of getting mad, you should be getting curious.

<comment><USER28> I am a PL researcher and I too believe you may not fully understand what's going on.

To keep your analogy, the idea that a PL needs syntax to be used is comparable to the idea that a vehicle needs acceleration to get moving. Different flavors of syntax correspond to different means of propulsion.

Perhaps we will find good way to get rid of context free grammars (the horses in your example) and replace them with automatic pruning of parse forests (the current Tesla car of compilers) or even something more fancy like semantic editors (a fusion engine in your example) but unless you change the laws of physics, you can't get a vehicle without an accelerating engine nor a PL without an input syntax.

</comment></comment></comment></comment><comment><USER29> The level of dedication is required is really high. I stumbled upon [https://github.com/oridb/mc](https://github.com/oridb/mc) and found my new favourite language written entirely by one person over the course of many years.

</comment><comment><USER30> He got the thing about using context-free grammars right. The final comment about not using generators is currently right, but will hopefully be wrong by the end of this year. :-)

</comment><comment><USER31> Do not know why this old page is revived again, but a better title would be "So you want to write you C or C++ like own language?".

Among other points is the trailing semicolon. If this is so good, then the authors of Go and Swift must be wrong.

<comment><USER32> I don't think you can say one is objectively right or wrong. However, as someone who's programmed for nearly 40 years, the entire issue seems like a fetish. Would anyone choose a language solely based on whether separators were required or not? Is your productivity dramatically increased by the choice of required separators? Of course not.

In functional languages there are some reasonable needs that make not requiring a separator useful. But, it does make the code harder to parse and harder to read. Go, for instance, is not a functional language. Making separators optional (sometimes) seems capricious. But, then, Go is rife with capricious choices.

<comment><USER33> Go uses semi-colon insertion like Javascript does, albeit with the benefit of Javascript's experience to fix up the edges. Calling "adopting some of the syntax of arguably the most popular language" capricious is probably stretching a bit.

<comment><USER34> I don't see why anyone would even think that a band-aid solution like "automatic semi-colon insertion" is a good idea. If you want optional semi- colons you have to change your language's syntax.</comment></comment></comment></comment>


Ask HN: How did you get your first freelance project? - <AUTHOR>

Trying to find different options in the freelance area on how to get the very first project to work on. Fellow HN'ers, please post your experiences. <comment><USER2> Networking is the most important. I built my first website for the small company I was employed. At one point a customer contacted my boss about who built the website, and he referred to me. (Which I'm still grateful for!). The next client: also within my network. Once you've done a few gigs, people will find you for work if you're good at it. Which brings me to the next point:

Underpromise and overdeliver. Always.

Just doing a good job isn't enough for people to reference for you. You have to be better than they expect. Client asks for two designs to choose from within two weeks? You give him three designs in one week, and tell them which one you like the best and why. That kind of stuff. Once you've secured the project, be communicative about progress and (especially) delays. This all may sound simplistic, but it would surprise you how many big shot agencies don't do these things.

Odesk/Elance? It's not working for me. I'd rather make a website for free for someone I know personally, with the intent of building a network and a portfolio, than building a website for a couple of tenners for someone on the other side of the planet.

</comment><comment><USER3> Its all networking. I would setup a good looking portfolio and start emailing other HN members. That will get you a fair amount of initial work. Then its just a matter of more networking. I also had good luck doing cold emails to people on LinkedIn.Just make sure to have a portfolio. People want to see what you have _done_ , not hear about what you can do.

I will warn you: in order to maintain a good volume of work you have to become good at marketing. If you do not look forward sales, and or negotiations, you might be better off working with an agency. Less money, but less hassle.

</comment><comment><USER4> As a full-timer looking to start freelancing on the side, I'm interested in this as well. I've heard too many horror stories about oDesk and friends. A popular approach I've heard is doing pro-bono work and getting a referral, but I feel like that would fall into the trap of "well you did that guy's stuff for free, what about me?"

<comment><AUTHOR> same boat here. Haven't heard any such personally, but got to know these sort of stories now and then. That's the reason I posed this on HN and looking for some valuable suggestions.

</comment></comment><comment><USER5> Networking. A friend of a friend needed a website. When you're freelancing everyone is a potential customer. Early freelancing projects are not that hard to get, it's much more difficult to turn a small portfolio into a reliable revenue stream.

</comment><comment><USER6> elance, odesk, etc are fine, it's just that the signal to noise ratio is very bad. Filter through the projects until you find reasonable projects with reasonable budgets.

Post on the seeking freelancer thread. I posted on there for the first time this month and have received a few contacts but unfortunately took on a large job right after doing so, so I haven't been able to take advantage.

Put together a portfolio if you don't have one already.

Network. Go to local events if you can, developer meetups but also things like chamber of commerce meetings. Keep in touch with your clients. Eventually, the bulk of your work should come from your network.

<comment><AUTHOR> +1 for things elance, odesk and pointing about the noise in them. HN Freelancer thread is great for this stuff, but I guess that works only when you have an established portfolio and handful of stuff done outside of your regular job. I did get some contacts from this thread, ultimately to zero leads. The possible way is to have good portfolio so these contacts can be turned to some leads.

</comment></comment><comment><USER7> I'm currently working on my first freelance project.

I got it through this guy I worked with at a company. He was my desk neighbor, he liked my work, I told him I was looking for freelance work and he told me he could use some help.

</comment><comment><USER8> I just started freelancing this week. I got lucky and was able to get work from my network which I thought was terrible. And I went on elance and may get a job there. But the rates on elance and similar websites are really low.

</comment><comment><USER9> I have a IFTTT script that crawls Craigslist for specific keywords and then it emails me the hits. Craigslist generally has a low signal to noise ratio, but I have landed a few things from there.</comment>


Touching on Apple's Mouseless Future - Is Apple about to kill mouse? - <AUTHOR> http://www.unboundedition.com/content/view/2940/

<comment><USER2> The more computer interfaces get like games, the better they get and the worse they get. It depends on the skill level of the operator.

<comment><USER3> You should separate the notion of the interaction modalities (mouse, touch screen, voice, etc), from the ways they can be used in various different types of software. New modalities such as touch screens will require designers to rethink how the user interacts with their software, but it doesn't change the goals of the user.

From a user's perspective, games and productivity software are fundamentally different. The point of games is to have fun. The point of productivity apps is to get things done. I saw the lead designer of Halo give a talk at school several years ago, and he used this example -- 'if we designed games to be like productivity apps, then the ideal game would consist of a big red button which said "Press me to complete game!" ' Social networking applications lie somewhere in the middle of the spectrum. You're not necessarily there to 'get things done'. You're there to linger as in a game - yet you do have more concrete goals and knowledge of your path/environment than you would if you were in a game.</comment></comment>


(Ab)using the C Preprocessor - <AUTHOR> http://altdevblogaday.com/2011/07/12/abusing-the-c-preprocessor/

<comment><USER2> Somewhat reminds me of the Life simulation in the C preprocessor (an IOCCC entry): <http://www.ioccc.org/years.html#1993_dgibson></comment>


Google Sneaks up on Identity Management - <AUTHOR> http://webworkerdaily.com/2007/12/16/google-sneaks-up-on-identity-management/ http://www.google.com/help/profile/ <comment><USER2> _"On the other hand, it's also possible that they could shop the combination around to other sites as their own answer to Passport and OpenID - a universal web identity backed by a trusted brand."_

[Sigh]

A universal web identity should _not_ be "backed" by any particular brand. That's precisely the strength of OpenID (and _not_ MS Passport). You're free to use any OpenID provider which _you trust_ (including _yourself_ ), but you aren't _required_ to use anyone in particular, like this guy suggests Google could/should do.

For example, I recently set up my personal website URL to be my OpenID (very easy: two additional <link> tags), which currently delegates to an account I registered with the myopenid.com provider, but I could easily change it at any time to another provider if I found another better provider that I trusted more (or even myself using something like <http://siege.org/projects/phpMyID/>)

Now, if Google wanted to be an OpenID provider (like AOL, LiveJournal, Technorati, WordPress, and others have done) I would be all for that. What we _don't_ need is some proprietary system.

I suggest anyone developing a web app look into supporting OpenID authentication. It's not too much additional work, and it would make the web a better place if it were widely deployed. Plaxo has detailed instructions on converting existing web apps to support OpenID: <http://www.plaxo.com/api/openid_recipe>

And for the rest of you, you should set up an OpenID and start using it wherever possible. Sam Ruby has good instructions on using your URL as an OpenID [http://www.intertwingly.net/blog/2007/01/03/OpenID-for- non-S...](http://www.intertwingly.net/blog/2007/01/03/OpenID-for-non- SuperUsers) or OpenID.net has information on getting an OpenID from any number of providers: <http://openid.net/get/></comment>


Personal Cloud platform Tonido welcomes php developers to write apps  - <AUTHOR> http://tonido.posterous.com/personal-cloud-platform-tonido-now-supports-p

<comment><USER2> Great Step! php support would accelerate innovation around Tonido..

</comment><comment><USER3> does it support php-db calls as well.....

<comment><AUTHOR> yes it does

</comment></comment><comment><USER4> Do you have a sample PHP plugin?

<comment><AUTHOR> yes <http://developer.tonido.com/phpdev/phpdevplugin.zip></comment></comment>