Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Comment Re:Switching (Score 2) 147

> 3) Do either of them save as .DOCX or .DOC, since that seems to be what most employers and recruiters insist on sending/receiving?

Since you mentioned employers/recruiters, I assume you are talking about a resume?

If so, use PDF for resumes. Sending resume as and .doc/.docx is not professional.


Comment government organizations to dissolve (Score 0) 317

The United States could safely eject several organizations which do not represent the interests the general public:

Department of Agriculture
Chamber of Commerce
Department of Justice

and probably several more

will never happen.
Instead we will nominate more czar's of random things, then that person turns into a department ... That's how we grow government, and no party has real desire to reverse it.

Comment Re:not the only coutry (Score 4, Informative) 236

> Base 12 is arbitrary

Not really.

It is chosen because it is divisible by 1,2,3 and 4.

You want also divisible by 5. 60. There are reasons why 12 and 60 have been common for time and measurements. So you can describe fractions of something without fractions (or decimal).

10, on the other hand, is less interesting, except that you can count to ten easily on your fingers. (The reason why it was chosen).

Comment If roads were not free, would you still drive (Score 1) 654

Even with free public transit, the government spends far more providing roads (for free) to private/individual cars.

If all roads were toll roads, would you still drive.

If the budget for private/individual transportation was equal to the budget for public transit, which would be preferred?

Comment No. Use optimal language(s). Write less code. (Score 1) 296

A few suggestions:

1. If possible, do not write new code.
If there is open source that does something close use that, and update for your needs.

2. Use a language that fits the problem.
It could be nodejs for certain complex http state machines. It could be python for high level applications. It could be C or assembly for low level performance requirements.

3. Don't limit to one language. Sufficiently large applications are usually implemented in several languages. Not purely for programer preference. But because it fits. If you write 1000 lines of C++ for a task that could be done in 20 lines of python or nodejs, then you are doing something wrong.
Solving the same problem twice (in multiple languages), will often help in design but also in revealing the optimal choice.

4. Keep code modular, so you can easily replace an implementation( with a new language or new design). Modular, meaning split at a library/executable/networking boundary, not "Object oriented", which does not necessarily aide with any software engineering principal.

Comment Re:Prototypical (Score 1) 80

I assume they just grew tired of the uniformed C++ masses saying. "JS is not 'real' OO, `cause it has no classes".

Classes are not required for objects, obviously. JS always had objects with properties and methods. And while using objects as prototypes for creating other objects is different than a Class based system, objects are still objects.

They just caved, and added class syntax sugar. You can still use JS the original/correct way, and ignore the class syntax.

I guess the class syntax does help those C++ programmers, who in the past insisted on creating ugly class wrappers in JS. At least their c++'ized code will be slightly less ugly.

Comment How? Fork Ubuntu? Use Devuan? (Score 1) 347

I am a skeptical.

Will Mint really fork Ubuntu? And keep an Upstart optional system?

An easier path, is perhaps have two paths (as Mint currently has).

An Ubuntu based system, which would have SystemD,

And a Devuan based system, which would offer other init systems. (The Devuan system would replace the Debian derived Mint).

Take your work seriously but never take yourself seriously; and do not take what happens either to yourself or your work seriously. -- Booth Tarkington