India approves New Education Policy 2020; Coding to be taught from class 6 - <AUTHOR> https://indianexpress.com/article/education/new-education-policy-2020-live-updates-cabinet-approves-nep-ramesh-pokhriyal-prakash-javadekar-6529139/ <comment><AUTHOR> Some other features

1\. Will set up Gender Inclusion Fund and Special Education Zones to make education more inclusive.

2\. Every child should have one vocational skill by the time they complete school. Besides, the school system will integrate vocation education and internships from Class six onwards so that students learn new skills. The assessment system will be comprehensive and shall use artificial intelligence to show the learning outcome, the short comings and what corrective measures are required.

3\. There will be no rigid separation between arts and sciences, curricular and extra-curricular. All subjects like music will be taught.

4\. School curriculum to be reduced to core concepts and there will integration of vocational education from class

5\. Students can intern with local crafts and trades for 10 days. For example, a student can work at a local laundry.

6\. The NEP plans to reduced the importance of Board exams. Board exams to be split into two parts - objective and descriptive. Instead of exams being held every year, school students will sit only for three - at Classes 3, 5 and 8. Assessment in other years will shift to a "regular and formative" style that is more "competency-based, promotes learning and development and tests higher- order skills, such as analysis, critical thinking and conceptual clarity". Board exams will continue to be held for Classes 10 and 12 but even these will be re-designed with "holistic development" as the aim. Standards for this will be established by a new national assessment centre - PARAKH (Performance Assessment, Review, and Analysis of Knowledge for Holistic Development).

7\. Medium of instruction should be mother tongue or regional language till class 5, preferably till class 8. However, the policy also says "no language will be imposed on any student".

8\. Report cards will include students' self-assessment as well as by teachers.

<comment><AUTHOR> 9\. Central and State governments will work together to achieve expenditure of 6% of GDP on education.

10\. Technology will be used in education planning, teaching, learning and assessment, administration and management and regulation.

11\. A National Research Foundation (NRF), tasked with creating a conducive ecosystem for research through funding and mentoring will be set up.

12\. Will allow foreign universities to set up campuses in India

13\. Change in the format of undergraduate education with the reintroduction of the four-year multidisciplinary bachelor's programme with exit options. While the three-year traditional BA, BSc, as well as BVoc degrees will continue, under the four-year programme students can exit after one year with a certificate, after two years with a diploma and a Bachelor's degree after three years.

14\. High-quality programmes and degrees in Translation and Interpretation, Art and Museum Administration, Archaeology, Artefact Conservation, Graphic Design, and Web Design within the higher education system will also be created.

15\. Touring by students to different parts of the country, which will not only give a boost to tourism but will also lead to an understanding and appreciation of diversity, culture, traditions and knowledge of different parts of India.

16\. Languages must also have consistent official updates to their vocabularies and dictionaries, widely disseminated, so that the most current issues and concepts can be effectively discussed in these languages. Standardization of Indian Sign Language (ISL) across the country.

17\. Setting up of an Indian Institute of Translation and Interpretation (IITI) while also laying significant emphasis on Sanskrit and other Indian languages. As per the NEP and IITT will be established that will make extensive use of technology to aid in its translation and interpretation efforts.

<comment><AUTHOR> 18\. As per National Education Policy 2020, the 10+2 structure in school education will be modified with a new pedagogical and curricular restructuring of 5+3+3+4 covering ages 3-18. The foundational stage will cover ages 3-8, while the preparatory stage will include Classes 3 to 5. The middle stage will cover Classes 6-8 and secondary stage includes Classes 9 to 12. In detail, The 5+3+3+4, will consist of 12 years of school and three of Anganwadi or pre- school. This will be split as follows: a foundational stage (ages three and eight), three years of pre-primary (ages eight to 11), a preparatory stage (ages 11 to 14) and a secondary stage (ages 14 to 18). According to the government the revised structure will "bring hitherto uncovered age group of three to six years, recognised globally as crucial stage for development of mental faculties, under school curriculum".

Preparatory Stage (Grades 3-5, covering ages 8-11) will see introduction of experiential learning across the sciences, mathematics, arts, social sciences, and humanities.

The Middle stage covering Grades 6-8, (ages 11-14) will have a subject- oriented pedagogical and curricular style.

And the Secondary stage (Grades 9-12 in two phases, i.e., 9 and 10 in the first, and 11 and 12 in the second, covering ages 14-18) will have greater depth, greater critical thinking, greater attention to life aspirations, and greater flexibility and student choice of subjects, and option to exit at grade 10 and re-enter at a later stage in grade 11

Each of the four stages of school education, may consider moving towards a semester or any other system that allows the inclusion of shorter modules.

19\. Mathematics and computational thinking to be given increased emphasis throughout school years. Activities involving coding to be introduced in Middle stage.

<comment><AUTHOR> 24\. Stand-alone agricultural universities, legal universities, health science universities, technical universities, and stand-alone institutions in other fields, shall aim to become multidisciplinary institutions offering holistic and multidisciplinary education.

25\. All institutions offering either professional or general education will aim to organically evolve into institutions/clusters offering both seamlessly, and in an integrated manner by 2030.

26\. Both capacity and quality of agriculture and allied disciplines must be improved in order to increase agricultural productivity through better skilled graduates and technicians, innovative research, and market-based extension linked to technologies and practices.

27\. Institutions offering agricultural education must benefit the local community directly; one approach could be to set up Agricultural Technology Parks to promote technology incubation and dissemination and promote sustainable methodologies.

28\. Legal education needs to be competitive globally, adopting best practices and embracing new technologies for wider access to and timely delivery of justice.

29\. Healthcare education needs to be re-envisioned so that the duration, structure, and design of the educational programmes need to match the role requirements that graduates will play. There shall also be a much greater emphasis on preventive healthcare and community medicine in all forms of healthcare education.</comment></comment></comment></comment>


Offer HN: I'll build your iPhone/Android app - <AUTHOR>

I'm a bit of a web generalist and I'm looking to get more into app development (on a freelance basis). However I need a bit more of a portfolio before I'm confident enough to get started properly. So in this respect, I'm offering to build someone (or someones) an iPhone or Android app. If it's something interesting or fun then all the better!
I can also do some light backend work if needed, but I don't really want to get into massive API's - so if you need that sort of thing too, you'll have to take care of it.
IMPORTANT
- The app will be developed with Appcelerator Titanium (http://www.appcelerator.com). While it will make use of native components and the like, it is not Objective C. I know JS/Titanium far better at the moment. If that's a deal-breaker, then sorry :)
- I have an iPhone 4 and Samsung Galaxy S2 to test on devices. I do not have an iPad other than the simulator. So if you want an iPad app, bear this in mind.
- Please bear in mind that given the platform, stuff like 3D games etc are not really feasible.
I will of course deliver all source code and assets, which will be your property upon completion. You will need to agree that I can mention the app in my portfolio though.
I'm not seeking any kind of payment for this, but if all goes well and you're extra happy with your app, you could always shout me a Macbook Air :)
Email me on veiledprawn at gmail for more or to discuss! <comment><USER2> Why wouldn't you dream up your own simple app and do that? Nothing makes a portfolio more than a published app. Or are you trying to avoid the actual publishing side and just want the experience of app creation?

I would say that the act of publishing an app is just as important an experience as writing the code.

<comment><AUTHOR> I realised after I posted that I could have explained this better.

To me at least, working to someone else's plan gives me a 'better' experience for future work. This way I'm not likely to artificially limit myself and drop features here & there because I don't feel like doing them. It will also give me more satisfaction to see a real useful app out there, than a flashy toy I might create to show off. I have some ideas of my own but that's all they are at the moment. And finally, someone else will get something useful out of it too.

And I do have a published app on the app store (should have mentioned that too!). It's an early experiment with PhoneGap and so not the best example of my skills however.

<comment><USER3> If you're looking to do this as a career, nothing beats an app you made yourself. I would give it much more weight in deciding whether to choose you as a developer than work you did for someone else. I don't know how much work you did on that other project, but I know with your own app you not only did it all, but you've shown me you can execute things on your own time without me bugging you. I suggest doing another one of your own apps, only make it kick- ass this time. Not necessarily in terms of have tons of functionality, but make it spiffy in the looks department and how snappy it is. A good suggestion would be an app that both solves a problem you have and shows off your skills.

</comment></comment></comment><comment><USER4> Do you anyone i could pay to develop a Spotify App?</comment>


Army officials ask NY public for help finding lost missile - <AUTHOR> http://news10.com/2015/08/29/army-officials-ask-ny-public-for-help-finding-lost-missile/ <comment><USER2> It's just a dummy missile. It doesn't contain explosives or propellant. It's basically just a weight of the same size, shape, and appearance as a Hellfire missile. It's used during training to give the helicopter the same weight load and distribution and same aerodynamics that it would have if it were actually armed. Ground crews also use them to practice loading and unloading missiles.

Some of these do contain real seeker heads so that they can be hooked up to the aircraft and the crew can practice locking onto a target.</comment>


It will take Intel years to fix its chipmaking process, analyst says - <AUTHOR> https://www.cnbc.com/2018/08/24/analyst-amd-will-gain-market-share-at-the-expense-of-intel-rivals.html <comment><USER2> > citing the chipmaker's process manufacturing advantage versus Intel and > Nvidia.

what they say is:

"We believe AMD has a multi-year advantage vs. Intel in CPUs with 7nm and a 6-month plus advantage vs. Nvidia in GPUs for the datacenter."

Neither AMD nor Nvidia manufacture their own GPU's, While there can be a prosess advantage, it must be much smaller. Nvidia has multi year software advantage in GPU's over AMD so I don't think AMD has real advantage over Nvidia.</comment>


2015 – 2020 Dietary Guidelines for Americans [pdf] - <AUTHOR> https://www.dietaryguidelines.gov/sites/default/files/2019-05/2015-2020_Dietary_Guidelines.pdf <comment><AUTHOR> There's been a lot of discussion about food and healthy eating around here... often discussing startups such as Impossible Burger, or dietary meal supplements (or meal-replacements) such as Soylent Green.

Ultimately, I usually defer to the advice from the USDA. While the advice changes somewhat over time, the general discussion points remained the same. The Food Pyramid may have gone obsolete, but the idea of eating a variety of vegetables, fruits, grain, protein... while restricting fats, sugars, and salts... has remained constant throughout the years.

<comment><USER2> Interesting. Whenever the topic is nutrition, the official guidelines are often criticized. Which always left me puzzled - I wouldn't even know if my country had some kind of official advice on that. Let alone follow them. But in the US that seems to actually have some kind of authority.

Besides that, and just carefully: After skipping over that document, I'm confident that it contains grossly outdated advice to the point where doing the exact opposite might not be worse. Especially on topics like saturated fats, salt intake or cholesterol.

<comment><AUTHOR> > About half of all American adults have one or more preventable, diet-related > chronic diseases, including cardiovascular disease, type 2 diabetes, and > overweight and obesity.

Some of the advice may be specific to Americans. Since Type 2 diabetes and obesity are so common in America, it makes sense to reduce saturated fats, salt intake in the USA.

\</comment></comment></comment><comment>--

Note: the 300mg of cholesterol recommendation was removed in this 2015 edition. The limitations are salt, sugar, trans fats, and saturated fats.</comment>


Can Language Shape How We Think? - <AUTHOR> http://www.stanfordalumni.org/news/magazine/2010/mayjun/features/boroditsky.html <comment><USER2> Fascinating. For so long the Sapir-Whorf Hypothesis ( _badly_ named linguistic relativism) has been out of favor, especially with Pinker's popular book "The Language Instinct." It's nice to see some real research in the area again, especially since it is investigating the effect we all see that seems at odds with the current linguistics stance.

I'd just like to know what's really going on.

Some related submissions:

<http://news.ycombinator.com/item?id=1543871>

<http://news.ycombinator.com/item?id=1505365>

</comment><comment><USER3> I think so. You can see less educated people struggling to understand or express subtle topics. A richer language allows you to think with a richer palette of shades.</comment>


Ask HN: Replacing NodeJs API, What Framework? - <AUTHOR> I am having some scalability issue with a nodejs backend and was considering a full rewrite, as it was initally developed as a "prototype" that became the production app. I've been exploring using python with Django or perhaps using Go with Gin, it needs to support a few common things, mongodb, redis, twilio (http api) and saleforce. I know its a little vague, but i want to gauage opinion on what the right tool is to make the scaling cheaper. <comment><USER2> Go scales real well and is a joy. If you are more comfortable with classic OO paradigms Java spring (or even spring + kotlin I hear) might be an easier transition and scales real well. (Disclosure: employer maintains/develops spring, I've used it a bit)</comment>


CSS Stats - <AUTHOR> http://cssstats.com/ <comment><USER4> hey CSS Stats - let me know if we can sponsor you. chris at maxcdn com - <USER2> get you an account right now.

</comment><comment><USER5> This is awesome in a "now I want to spend ages refactoring my CSS to make my numbers look awesome" kind of way.

</comment><comment><USER6> I get only blank pages returned. Assuming it has buckled under the onslaught of HN visitors, what does it show when it works normally?

<comment><USER7> Apologies for the downtime. Should be back up now.

<comment><USER8> Still not loading here.

</comment></comment></comment><comment><USER9> What would this tool be useful for?

It almost seems like an on boarding tool for 3rd party CSS but you can't construct or derive style rules from any of the presented formats, just raw colors/sizes.

The charts and metrics all seem superfluous.

<comment><USER10> The specificity graph is quite meaningful. For example, compare the specificity graphs for Yahoo ([http://cssstats.com/stats?url=http%3A%2F%2Fyahoo.com#specifi...](http://cssstats.com/stats?url=http%3A%2F%2Fyahoo.com#specificity- graph)) and Amazon ([http://cssstats.com/stats?url=http%3A%2F%2Famazon.com#specif...](http://cssstats.com/stats?url=http%3A%2F%2Famazon.com#specificity- graph)) - selected for both being public-facing sites of similar size.

Because CSS rules are applied by specificity ([http://specificity.keegan.st/](http://specificity.keegan.st/)) first and source order second, any property overwrites later in the document require equal or greater specificity than rules in the middle. A chart with a mountain in the middle today will probably develop more mountains on the right over time - it's a leading indicator of poor maintainability. Pairing this tool with one that tells you the line number of offenders would help in identifying areas in need of refactor.

Total vs Unique declarations reveals opportunities for reusable OOCSS-type classes (which itself can be difficult to do in a stylesheet full of specificity mountains).

The colors aren't terribly useful without a histogram and some of the other stats do seem a bit superfluous, but they may just need someone more experienced than I to draw the right conclusions.

<comment><USER10> Amazon might not be the best example - <USER3> [http://cssstats.com/stats?url=http%3A%2F%2Famazon.com#specif...](http://cssstats.com/stats?url=http%3A%2F%2Famazon.com#specificity- graph) multiple times has generated multiple, _very_ different graphs. I wonder if the CSSStats bot has been thrown into more than one A/B experiments.

<comment><USER7> It's not currently grabbing all of the stylesheets - we are working on a fix for this at the moment.

</comment></comment></comment></comment><comment><USER11> If you'd like to collect similar stats for your own code base, check out parker[1] and stylestats[2]. At my company, we aggregate certain numbers from both tools and send them to Graphite to monitor over time, as inspired by this talk from GitHub[3][4].

[1] [https://github.com/katiefenn/parker](https://github.com/katiefenn/parker)

[2] [https://github.com/t32k/stylestats](https://github.com/t32k/stylestats)

[3] [https://speakerdeck.com/bleikamp/sass-at- github?slide=68](https://speakerdeck.com/bleikamp/sass-at-github?slide=68)

[4] [https://vimeo.com/86700007](https://vimeo.com/86700007)

</comment><comment><USER12> Doesn't support gzip compressed files? I'm getting back garbage from my production css file.

<comment><USER7> Please feel free to open an issue and let us know specifically what is going wrong

[http://github.com/mrmrs/cssstats/issues](http://github.com/mrmrs/cssstats/issues)

Thanks!

</comment></comment><comment><USER13> Is there a browser extension version of this so that it can be run on pages that require authentication?

<comment><USER7> We don't have one yet - but that's a great idea. We'd like to support basic auth somehow.

</comment></comment><comment><USER14> I had no idea Facebook's CSS was so minimal (less than a kilobyte!). Bravo, FB.

<comment><USER15> I'm seeing 265 KB for Facebook's CSS.

[http://cssstats.com/stats?url=http%3A%2F%2Ffacebook.com&name...](http://cssstats.com/stats?url=http%3A%2F%2Ffacebook.com&name=Facebook)

<comment><USER14> Now I'm seeing 49kB. Strange. It's not cookies either because it's 49 in an Incognito window as well.

<comment><USER16> A/B testing I would assume.

</comment></comment></comment></comment><comment><USER17> Definitely will try to improve my styles to reduce unique definitions.

</comment><comment><USER18> The site loads very fast. That's impressive.

</comment><comment><USER19> Why not just host on aws?

<comment><USER7> It is hosted on AWS! I am just a dev ops n00b. Working out the kinks at the moment.</comment></comment>


Ask HN: Slack bot for monitoring depencies updates - <AUTHOR> Today I use RSS for keeping up to date with dependencies that we use in our software but would like to increase visibility for this in our team to get more buy-in for keeping up with bugfixes in our dependencies. I'm thinking of writing a Slack bot that can ingest a package.json file, monitor for new versions and when a new version appears post to some channel with details of the new release.<p>Do you know of something like this, I couldn't find anything on Google? Would you find it useful? <comment><USER2> You should have a look at Winds ([https://getstream.io/winds](https://getstream.io/winds)). It keeps everything in one place and visibility seems to be a top priority. Pretty cool app and it's available for web and desktop.

</comment><comment><USER3> You mean sth like Greenkeeper [https://github.com/apps/greenkeeper](https://github.com/apps/greenkeeper) ?</comment>


A Surge in Meth Use in Colorado Complicates Opioid Recovery - <AUTHOR> https://www.npr.org/sections/health-shots/2018/07/14/628134831/a-surge-in-meth-use-in-colorado-complicates-opioid-recovery <comment><USER2> This strikes as correlation not causation.

As someone in denver since before the legalization, i believe these stats are related, but i think the bigger cause was pot legalization in so few areas at once. By legalizing in CO and not nationally, my story is that we attracted a number of people looking to move for a lifestyle, not knowing that at the same time housing prices were skyrocketing due to a blooming tech scene and gentrification. The influx of smokers only added fuel to the fire.

The two ongoing trends create hard times for the un/underemployed. It is well documented that crimes rates correlate with hard financial times.

<comment><USER3> RE: Pot legalization - it could be you are correct.

I lived in Denver pre-/post-medical legalization. I now live in Northern CA where we just legalized.

Basically I've seen the same thing happen both places: Cannabis is legalized, and there is an uptick in violent and petty crime in the areas where cultivation is. Meth I don't know.

</comment></comment><comment><USER4> What will be interesting over the next 20 years is how legal weed will impact addiction rates.

<comment><USER5> Colorado's governor is having second thoughts about legalization.[1]

[1] [https://www.cnn.com/2018/04/20/us/colorado-marijuana-and- cri...](https://www.cnn.com/2018/04/20/us/colorado-marijuana-and- crime/index.html)

<comment><USER6> Is this a propaganda piece pushed by entrenched alcohol industry interests?

<comment><USER7> As someone who thinks marijuana should be legal, I thought it was a reasonable article.

<comment><USER8> The video embedded in the article pretty much made the point that legal weed brought transients to the state, and they are in turn people that would have committed crimes regardless of what state they are in. Legalizing nationally would negate the issue.

</comment></comment></comment></comment></comment><comment><USER9> Looking at the chart in the article, heroin overdoses have grown by about the same amount as meth.

</comment><comment><USER10> The speedball (stimulant+depressant) has long been popular. In the mainstream, that would be coffee plus alcohol, and often tobacco. For the hard-core, that would be cocaine or methamphetamine, plus morphine, heroin or eucadol. But without medical supervision, the risk of overdose is too high. Because opiates tend to wear off faster than stimulants, and titration is nontrivial.

<comment><USER11> Comparing the mix of moprhine and cocaine with coffee and alcohol is both misleading and inaccurate.

Even cocaine and amphetamine are apples and oranges, despite both being classified as stimulants.

<comment><USER10> Well, all combinations of stimulants and depressants are speedballs. And in my experience, they differ mainly in intensity. And of course, in risk of death. Which I did make very clear.

Anyway, it's basically that stimulants prevent falling asleep, passing out, or (ideally) dying at high depressant doses. Which allows users to experience more intense effects from said depressants. And that depressants reduce anxiety, relax, and (ideally) prevent dying (usually from cardiac arrest) at high stimulant doses. Which allows users to experience more intense effects from said stimulants.

And re cocaine vs methamphetamine, I've used both a lot, albeit many years ago. And sure, they're quite different. But they both made me happy, and kept me awake. As I recall, cocaine was much better for play, dancing, and sex. And methamphetamine was better for working, driving, and just slogging through emergency situations.

For a few years, I basically lived out of a bicycle, and I always carried methamphetamine and morphine, in case of emergencies. It was standard issue for most all military services, so hey.

</comment></comment></comment><comment><USER12> > when her parents gave her pain pills for a toothache. Just like that, she > was hooked.

I call B.S. The next paragraph reveals the cause ...

> Both my parents were addicts</comment>


Why have a "women's" leadership program? - <AUTHOR> https://medium.com/code-like-a-girl/why-have-a-womens-leadership-program-647aa25db630#.n0u1ti2y7 <comment><USER2> "Perhaps a group of men working for years in a women dominated profession might explore a men's leadership program."

Do such groups actually exist? I could see that maybe in the medical field, or in the media industry. But are there such initiatives?</comment>


How Microsoft rewrote its C# compiler in C# and made it open source (2017) - <AUTHOR> https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98 <comment><USER2> Roslyn's parser and syntax tree is pretty amazing. You can recreate the precise source text from the parse tree up to whitespace. This sort of "bijective parsing" is truly incredible and probably one of the cooler innovations I've seen in parsing technology. I can see a bunch of really interesting ideas that you could do with bijective parsing. For instance, imagine Rails style boilerplate generation but done at a semantics aware, within file basis. You could conceivably have a code generator that finds a class, introspects if it has the corresponding method, then generates it if not.

Or imagine syntax reformatting but purely locally. Or semantically aware git diffs that can actually compare the underlying parse trees instead of just raw text. There's so much cool stuff you can do. I wish every language had a parser like this.

<comment><USER3> Pardon me if I'm missing something, but doesn't just about any AST implementation allow recovering the source text up to whitespace – or indeed including whitespace, given that most real-world parsers have to retain lexical information in order to support reasonable diagnostic messages anyway.

<comment><USER4> There is reason AST is called abstract syntax tree not just syntax tree. Many syntax details like parentheses or choice between alternative syntax forms are there only to avoid syntactic ambiguity, improve readability or historical reasons and don't affect the semantics or even error messages. It's not surprising for compiler authors to choose discarding some of the unnecessary information as early as possible to save memory.

<comment><USER5> It's called abstract syntax tree because the concrete syntax is not a tree, it's an list of characters. Not because it makes _semantic_ -invariant transformations.

<comment><USER6> > It's called abstract syntax tree because the concrete syntax is not a tree, > it's an list of characters.

It's called abstract syntax tree to distinguish it from parse trees (a.k.a. concrete syntax trees).

</comment></comment></comment></comment></comment><comment><USER7> How would you compare special features, if any, as well as advantages (and disadvantages) of using C# for developing an _embedded_ DSL versus using Julia macros for the same purpose versus using specialized toolsets (e.g., MPS) for developing an _external_ DSL? Please note that I'm aware of the Modeling SDK for Visual Studio. However, since it only allows integration with / targets the Visual Studio environment, it is not a good general approach, hence the question.

<comment><AUTHOR> Maybe you can look at F#, it will compile for Android, iOS, windows, Linux, MAC, javascript frontends and server side. The feature set is different than Julia's but it is very powerful and versatile.

<comment><USER7> Thank you for the suggestion. Will definitely take a more detailed look at F#. I have read about it some time ago, including some very positive general feedback. However, even if F# is an excellent fit feature-wise, I can see two potential issues: 1) lack of a decent package ecosystem (since the planned DSL is only one part of multi-feature multi-aspect platform puzzle) and 2) lack of a significant enough pool of experienced developers, which would make building a good team a challenge (due to its relative popularity, C# is IMO much better than F# in this regard).

</comment></comment></comment><comment><AUTHOR> I find amusing how microsoft moved from the closed source referent in the industry into such an open source player. Right now even allows to hook some of their tools and platforms to its competing platforms and tools.

<comment><USER8> Their intent is still entirely market share. We need to be vigilant on how they get there. History has taught us a lot of lessons we seem to have forgotten because shiny and new layer of marketing. There is still a massive cultural and technical impedance mismatch.

<comment><USER9> I agree. A lot of what they are doing now looks like EEE when you peel back a couple of layers.

I say this as someone who happily uses a lot of the stuff they produce in the process. I really, really, intensely hope I'm wrong and my fears aren't realised.

<comment><USER10> It's the same corporate entity, but Microsofts incentives and the majority of executives have turned over. So I don't see any reasons why Microsoft would be any more likely to EEE than another company. In fact I think they would be less likely because they they have more to risk reputationally.

</comment></comment></comment></comment><comment><USER11> I've always loved C# but can't quite get past having to target specific .net frameworks and keeping the different frameworks in my different servers straight and targeting each of them differently. Maybe that'll change with .net core (and once I'm able to get that on my servers), but for now I've discovered a personal love for Go as a way around this for my small utilities.

<comment><USER12> .NET Core 3.1 is a good LTS release and no time like the present to start migrating to it. Unlike .NET Framework, there's a lot less emphasis in .NET Core on machine-wide installs and a lot more capabilities for application- specific framework deployments. .NET Core even has tools to bundle all of your framework dependencies into a single "EXE", and tree-shaking that down to at least something of a minimal bundle size. There's a small but growing world of "go-like" small utilities that are entirely self-contained .NET Core dependencies.

[https://www.hanselman.com/blog/MakingATinyNETCore30EntirelyS...](https://www.hanselman.com/blog/MakingATinyNETCore30EntirelySelfcontainedSingleExecutable.aspx)

There's even fun experiments of AOT compiling to get interesting in "EXE golf" results from .NET Core applications such as getting them below 8 KB or running on Windows 3.1 (because why not):

[https://www.hanselman.com/blog/NETEverywhereApparentlyAlsoMe...](https://www.hanselman.com/blog/NETEverywhereApparentlyAlsoMeansWindows311AndDOS.aspx)

.NET 5 will integrate further AOT capabilities as the Mono world is merging in, in addition to the raw marketing advantage that 5 > 4 for anyone still struggling to convince non-technical managers that .NET Core is a better investment in 2020 than .NET Framework.

</comment></comment><comment><USER13> While the rewrite enabled faster development of the language as a whole, it also gradually destroyed the IDE's performance. The editor in VS 2019 is simply unworkable.

I blame this directly on the immutable AST. While a nice concept in theory, it causes too many allocations, and is cumbersome to work with.

I predict another rewrite in 2 or 3 years.

<comment><USER14> I had to ditch ReSharper to get to 2019 because together with the performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and Roslyn does the same. It's not surprising since they basically do the same thing, in managed code! But I can't pay the CPU time and memory to analyze my code TWICE on every edit. I also suspect things like switching build configuration offers thousands of opportunities to have some IDE widget hold references to old compilation data structures which are never garbage collected. On the bright side at least 2019 works pretty well without R#.

<comment><USER15> > I had to ditch ReSharper to get to 2019 because together with the > performance of the IDE itself, it just wasn't usable. R# ate gigs of Ram and > Roslyn does the same. It's not surprising since they basically do the same > thing, in managed code! But I can't pay the CPU time and memory to analyze > my code TWICE on every edit.

I'm holding off on 2019 as much as I can. Between 'forcing' an upgrade for .NET Core 3.0 and the fact Resharper slows it down too much, I decided to give Rider a try.

I'm finding myself not missing VS a whole lot; on one hand Rider is taking way more RAM to start and load, but it stays pretty constant after the first debug session, winds up staying under VS for memory on longer loads (Especially if I've got multiple solutions open) and it's smoother than VS the whole time.

<comment><USER16> Is Rider 64-bit?

<comment><USER17> It is, but that's not too relevant, as the ReSharper component runs in another process (but that's managed code as well, so probably also runs as a 64-bit process).

</comment></comment></comment></comment></comment><comment><USER18> I still can't believe more people aren't leveraging the Roslyn APIs to write compiler extensions or additional tools around C#. It's conceptually powerful.

<comment><USER19> Personally speaking, I'd love to, but I'd then have to figure out how to make them work with an IDE. I'm very tired of waiting for record classes to show up and I could have written a (to be clear: _inferior_ ) set of stuff around regular classes that magics one into "everything is readonly and we autogenerate a `copy` method", much like Kotlin does for its data classes...but my IDE isn't gonna understand it unless I do a lot more work, and so I never bothered.

<comment><USER20> I'm not sure that it would be that difficult with Roslyn and Visual Studio these days. There _are_ Roslyn-based syntax-highlighters and linters and snippet-generators and code-transformers. I use one for making sure all of my code is not just formatted the way I want it, but auto-inserting "readonly" modifiers for fields that don't get re-written outside of the constructor, one that treats not implementing IDisposable correctly as an error (it can also track the lifetime of a Disposable object and warn when it detects that it never gets disposed, which is super cool), and another one that rainbow- highlights code blocks. The tooling is there to support just a thing, it just needs someone to put all the pieces together.

<comment><USER21> What is the name of that IDisposable checking one? That sounds very, very useful.

<comment><USER20> I think the easiest way to set it all up is to manually edit your CSProj files, especially if you are still building .NET Framework projects. By default, Visual Studio will only create the new SDK Style project file format for .NET Standard and .NET Core projects, but it's still usable for .NET Framework projects if you manually change the format. Once you change it, it sticks, so you can use VS to edit the config after that, but it's still pretty easy to edit by hand now.

So here is my base project config: [https://github.com/capnmidnight/Juniper/blob/master/Juniper....](https://github.com/capnmidnight/Juniper/blob/master/Juniper.props)

The most important part is the first PropertyGroup sets values for all build configs, in particular is setting LangVersion to 8.0. Framework 4.8 taps out at C# 7.2, but you can use most of the C# 8.0 features, including fully async streams if you manually set the language version. Features that aren't available are some minor things like the array ranges and indexing: [https://docs.microsoft.com/en-us/dotnet/csharp/language- refe...](https://docs.microsoft.com/en-us/dotnet/csharp/language- reference/proposals/csharp-8.0/ranges)

And here are my base project with the analyzers I use: [https://github.com/capnmidnight/Juniper/blob/master/Juniper....](https://github.com/capnmidnight/Juniper/blob/master/Juniper.targets)

They're all ones provided directly from Microsoft, though there are a bunch more from other vendors: [https://www.nuget.org/packages?q=analyzer](https://www.nuget.org/packages?q=analyzer)

Then here is an example project using that targets file: [https://github.com/capnmidnight/Juniper/blob/master/src/Juni...](https://github.com/capnmidnight/Juniper/blob/master/src/Juniper.Server/Juniper.Server.csproj)

You can see just how much the new SDK Style project file format simplifies things. There is no importing of any base Targets files hidden deep in Visual Studio's install directory anymore.

I manually import the .props and .targets file instead of using Directory.Build.props and Directory.Build.targets because I have other projects that use these configs, included via a git submodule.

Here is my .editorconfig file, where I set most of the rules related to Disposable types to errors: [https://github.com/capnmidnight/Juniper/blob/master/.editorc...](https://github.com/capnmidnight/Juniper/blob/master/.editorconfig)

And this Visual Studio extension makes .editorconfig files a lot nicer to work with: [https://marketplace.visualstudio.com/items?itemName=MadsKris...](https://marketplace.visualstudio.com/items?itemName=MadsKristensen.EditorConfig)

(BTW, I pretty much install all of Mads Kristensen's extensions)

And while I'm here, I'll give a shout-out to Viasfora for its syntax highlighting modifications that rainbow-highlight code blocks: [https://marketplace.visualstudio.com/items?itemName=TomasRes...](https://marketplace.visualstudio.com/items?itemName=TomasRestrepo.Viasfora)

And VSColorOutput for making the Output window in Visual Studio actually readable: [https://marketplace.visualstudio.com/items?itemName=MikeWard...](https://marketplace.visualstudio.com/items?itemName=MikeWard- AnnArbor.VSColorOutput)

</comment></comment></comment></comment></comment><comment><USER22> Why isn't the native code compiler also now written in C#, like Java is doing?

<comment><USER23> People have done research before into having the C#->native JIT be written in C#, I recall seeing prototypes. There are a ton of barriers between a prototype and a shipping implementation though, so I'm not sure we'll ever see it. In particular you risk regressions in startup time or memory usage since the amount of infrastructure needed to run C# (pre-jitted?) to generate all your jitcode is much higher than a small blob of hand-written C/C++ that's spitting out jitcode. See [https://www.mono- project.com/news/2018/09/11/csharp-jit/](https://www.mono- project.com/news/2018/09/11/csharp-jit/) for one example.

There's an old saying (from one of Unity's developers, I think?) that you can't run Hello World in C# or Java without an XML parser because so much configuration for things like locales ends up pulling in serialization libraries, reflection, etc. Things have improved in this area for both platforms but it's definitely still very difficult to trim managed code down as far as you can trim native code.

For something as critical as the JIT you also want to keep the generated code small (for cache efficiency) and if possible, PGO it - things that existing managed code generators aren't especially great at compared to clang or modern MSVC.

From my past experience writing/maintaining C# compiler and runtime code, I would never bother trying to port the JIT to C#. I don't think the returns are worth the massive investment. I'd sooner port it to a language like Rust for safety benefits or to some sort of hypothetical language that enables producing smaller/faster code to improve JIT performance. I'm not sure I'd invest in that either though because for most workloads JIT time is not the bottleneck (and you can optimize that out in many cases by pre-generating the JITcode). EDIT: Also, for workloads where JIT is the bottleneck, it's questionable whether it's possible to extract big gains out of optimizing the JIT because of the nature of JIT workloads - you may just be bottlenecked on memory bandwidth or instructions per clock. A JIT converting IR to machine code is not trivially vectorized.

People are figuring this out (again, from scratch) now with webassembly as all the modern browsers go through the churn and angst involved in answering the question 'can we actually JIT this whole 50mb executable from scratch at load time?' even though we already knew the answer back when WebAssembly wasn't a spec yet.

[DISCLOSURE: I get paid to work on Mono right now and was paid to help draft the initial WebAssembly spec, and before that my work on the JSIL MSIL->JS compiler was sponsored. So I have some massive biases here.]

<comment><USER22> The way Java does it is their JIT written in Java is optionally AOT compiled to native code, so it doesn't have a startup time or warmup time problem and it can be PGOd.

We do know that the returns are worth it, because people are able to develop new optimisations in the Java version that people just won't attempt in the C++ version because the code is so much harder to work with (but possibly just due to the age of the C++ version) and its achieving 13% speedup over the C++ version in practice at places like Twitter, which is worth millions of dollars.

<comment><USER23> This is fascinating. Is the claim here that the C++ version could have never been as fast as the current Java one or just that people have been optimizing the Java one and getting improvements past the C++ one?

Also, it sounds like the old C++ JIT has to be maintained and shipped in the event that the Java-based JIT isn't available at startup, right? If so that makes sense as a stop-gap and it would be more of a tiered JIT, not a port. Tiered JITs are definitely proven, successful technology.

<comment><USER22> > Is the claim here that the C++ version could have never been as fast as the > current Java one

The claim is that the work to add new optimisations to the old C++ code is so difficult that people aren't prepared to do it. The Java code is easier to write and debug, enough so that people are managing to add new optimisations that they haven't added to the C++ code.

> the old C++ JIT has to be maintained and shipped in the event that the Java- > based JIT isn't available at startup

Well only until the new Java JIT is mature. The AOT build of the Java JIT can be shipped in the binaries so it's always there.

> If so that makes sense as a stop-gap and it would be more of a tiered JIT, > not a port. Tiered JITs are definitely proven, successful technology.

It's used as a new top-tier yes, replacing the C++ top tier. The C++ JIT is likely to go I think, in the medium-to-long term.

</comment></comment></comment></comment></comment><comment><USER24> It should be noted they are now contributing to openjdk too!

</comment><comment><USER25> If .NET/C# could output native binaries for Windows Desktop apps, I could seriously think about switching to C# over C++. How do people deal with securing their source code otherwise? Quite trivial to get the source from a decompiled C# exe file.

<comment><USER26> It's quite trivial to get the source from a C# exe file in the same way as a decompiler makes it trivial to get the source from a C++ exe file.

Obfuscators are common if you're concerned about the symbols leaking.

If you don't include the .PDB debugging symbol files it's much the same as native binary code. The .NET virtual machine code is a little more expressive but is superficially similar to x86 native code.

In my opinion, if you're concerned about people reading your compiled machine code, the only solution is to run your app on a server and give users an API.

<comment><USER25> A C# binary can be decompiled back to easy to read source code. Show me how this can be done with a compiled C++ binary. It is a valid concern.

<comment><USER27> With IDA, HexRays, Hopper and a couple of Python scripts.</comment></comment></comment></comment>


On the history and justification of the C programming language - <AUTHOR> http://pastebin.com/UAQaWuWG <comment><USER2> This completely misses the key factor: (most) computers were not big or fast enough to run high level languages back then. So for people who only got to use small computers, they had to code in assembler (or cross-compile on a big computer).

So anyone who could come up with a high(er) level language that would run on smaller machines was a winner. It meant the difference between a life of misery hacking assembler or a life of milk and honey coding in a high level language. There was no "Oh, let's be stupid and omit <safety feature du jour> from our language". It was more like "Wow, I got a compiler to run on that PDP-11/20 and it only had to be split into 5 passes to fit into core".

There were many many simple languages back then that occupied this niche. Only C has survived into the modern era (thanks to open source compilers and Unix and Microsoft's adoption of C for WindowsNT). If things had turned out differently we would be complaining about the lack of safety in code stil being written in Bliss or IMP or PL/S.

<comment><USER3> _This completely misses the key factor: (most) computers were not big or fast enough to run high level languages back then_

From the 1st paragraph, that's what I thought they were going to talk about:

 _totally contradicts real reasons why C is designed the way it is. Even back then, there were better languages /OS's [1] that cheap hardware just hadn't caught up to. That cheap hardware's limitations, and them alone, drove the design decisions of BCPL, B, and then C._

But you're right, they're mostly talking about the compilers.

 _So anyone who could come up with a high(er) level language that would run on smaller machines was a winner._

I think that's what the Objective-C folks were thinking. I guess the author would lament that they chose C as the other partner.

 _Only C has survived into the modern era_

Forth was around in those days. So was Smalltalk and Lisp. So maybe, "survived as more than a niche language?" (Forth and Smalltalk are really from the 70's. You could argue that only Lisp is from "those days.")

<comment><USER2> I suppose I was thinking of the set of languages commonly used back then for programming smaller computers. Smalltalk definitely wasn't aimed at small machines. I guess I just woudln't include Forth and Lisp in that set. Not sure exactly why to be honest. Forth certainly ran on very small machines. Both were considered "weird" where I came from, but I acknowledge that isn't a universally held view ;)

<comment><USER4> Lisp first ran on a vacuum tube computer, it was definitely "small", and it can certainly run fairly nicely on current "small" machines, although not "very small" like I recall of Forth.

Smalltalk's machines weren't all that large by today's standards, memory was 128kB, expandable to 512kB per Wikipedia, but expansions were addressable only by bank switching. 128kB is the same memory budget as the Unix PDP-11/45's for a single process.

<comment><USER5> Didn't know Smalltalk constraints were similar. Might have to add Smalltalk in the essay somehow. Which computer did LISP start on again?

<comment><USER6> IBM 704 - [https://en.wikipedia.org/wiki/Lisp_(programming_language)#Hi...](https://en.wikipedia.org/wiki/Lisp_\(programming_language\)#History)

<comment><USER5> Thanks! Wow. That's some tough hardware to work with. So, both Fortran and LISP developed on the same machine. Guess I just never thought about the LISP hardware given I started with the AI books & went straight to modern work. Had I done so, I'd have wondered less about whether it could work in constrained environments haha.

<comment><USER6> You view things perhaps too much through modern eyes.

For them, that was some amazing hardware to work with. A lot of new ideas were tested out on the 704.

<comment><USER5> Oh yeah, Im sure. Im using modern eyes intentionally in context that many people think a LISP or dynamic language can't run on constrained hardware. The 704 was pretty constrained by today's standards. Refutes that claim.

<comment><USER6> No, you weren't using "modern eyes intentionally in context". You wrote "I'd have wondered less about whether it could work in constrained environments", and your description comes across as unintentional. That's what I'm referring to.

I grew up with microcomputers. My first machine had 16K, which I think is about what a 704 had. There's a lot you can do with 16K. Altair BASIC ran on 4K machines. Even modern micropython, meant for microcontollers, works in 64K, and that language wasn't designed to be space efficient.

Oh, and from [http://edn.embarcadero.com/article/20693](http://edn.embarcadero.com/article/20693) :

> Turbo Pascal version 1.0 shipped on one floppy disk. The total number of > files on the disk was 10. Total floppy disk space used was 131,297 bytes. > Total size of TURBO.COM (including the integrated development environment > with compiler, Wordstar-style editor, and run-in-memory system) was 33,280 > bytes.

<comment><USER5> "No, you weren't using "modern eyes intentionally in context". You wrote "I'd have wondered less about whether it could work in constrained environments", and your description comes across as unintentional. That's what I'm referring to."

You're putting a lot of weight into words I wrote casually. The intended meaning was that I hadn't investigated what a good, useful-today implementation of LISP could do in what would be a highly-constrained system today. Particularly, on cheap microcontrollers used in embedded systems. I have seen LISP's like femtolisp that use around 1K for implementation with good performance. So, original LISP being able to run on a 704 implied quite a lot to me.

On other hand, BASIC and Pascal are low-level, static 3GL's. They're easy to compile efficiently into efficient code even without much optimization. I pulled it off for BASIC without knowing much about compilers. I'm sure it took talent to get the mix of functionality and efficiency in stuff like TurboPascal or some of the Altair apps. It's not telling me much about how a dynamic LISP will work on those platforms, though, given its execution style is so different. Especially if I code in a way that doesn't penalize readability or maintenance for efficiency.

Fortunately, there's a pile of papers I can go through if I want to determine an optimal way to do that. Many of which are from 70's-80's. The 704 result just tells me embedded impact could happen if I kept it efficient. Micropython work is also impressive. I hope the point of my reply is more clear now.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> > There's a recurring theme where people think the C language's design is good > for systems programming, even today. These people think that someone sat > down, thought of every tradeoff, and made the best ones for system > programming.

Or, people think that a good practical language can only come from using it to solve real problems and iterating on the design. Sitting down and conjuring up the perfect language just does not work.

Now, I am the first to agree that C has plenty of flaws. For one, the integer types are just a mess. I will be happy if something can replace it, but so far most attempts have ended up either too slow or too complicated.

<comment><USER8> An example of convergent evolution -

Apple was primarily a Pascal shop back in the early 80s, when they were developing the Lisa. But since bog-standard Pascal is useless for systems programming, Apple extended it with things they needed: Pointer arithmetic ( _not_ auto-scaling by base type, so you were constantly multiplying by sizeof), oh yeah, sizeof, and a bunch of other stuff I've forgotten. Pascal's miserable I/O system was left on the floor. NEW was largely replaced by a heap manager that worked for small systems. And so on.

So what Apple wound up with was "C, with nested procedures". The two languages were nearly identical in semantics. I could spend a day hacking on something, and if you asked me in the evening which language I'd been using I would have had to think about it.

The types of bugs that people wrote didn't seem to vary depending on the language they chose.

My informal survey is that other companies extended their versions of Pascal, making similar choices. These companies (Apollo? a few others) have sunk without a trace.

Languages that look a lot like C are what you get from systems level people doing near-bare-metal programming. You're not going to fix the language, you need to convince the people doing the work that you have something better. And for the most part, something better doesn't exist.

You _can_ write low-level systems in higher-level languages; Microsoft's Midori was an OS from the metal-up in C#, with a lot of interesting deep thinking about abstractions and security. SmallTalk / SELF / FORTH are interesting until you need to scale. LISP Machines didn't take the world by storm in the 80s, and we didn't get very interesting fallout from all the LISP-based OS work that was being done. ADA . . . I know one guy who loves ADA, but he can't tell me what he works on.

Successful languages seem to be the result of commercially successful systems, not the other way around.

<comment><USER9> This is exactly what I think of when I read this kind of unilateral negativity about C. I love writing programs in C. I don't need to learn any new semantics ever. Even the integer types, as parent was complaining about, have been largely cleaned up(I use (u)int(32,64)_t and (s)size_t and everything just works.

The problem space is well understood, the tools are widely-deployed and reliable, the performance is excellent. I just don't see how people can be so negative about something which has been so immensely useful without getting in the way.

<comment><USER10> Op probably meant that C integer types are a mess because they underflow, overflow or result in undefined behaviour at the smallest mistake. :)

</comment></comment></comment></comment><comment><USER11> The best things always have detractors, yet they live on.

C is over 40 years old and is still in widespread use today, even though there have been (supposedly) better languages targeting the same use cases for decades now. There is more to it than just inertia.

I've been using it less and less over the years, mostly because I've also been tackling less and less problems in the domains where it excels. It is still my favorite language though.

<comment><USER12> I respectfully disagree. I think C is a giant disaster that will continue to plague us entirely due to inertia. You're really underestimating how entrenched it is. Try to go program on micro in something other than C. Try programming a driver. The toolchains simply don't exist - the comparability with several decades of work is also shaky.

C is a terrible cross platform assembly b/c it doesn't allow you the level of control which one would expect in this day and age. Maybe it was written in the days when CPUs were brain-dead simple, but basic things that are available on most architectures aren't part of the language. It has no notion of a CPU cache, it has no notion of branching (you can't tag a likely branch and an unlikely one), it even goes as far as to ignore user keywords for inlining and provides no keyword for blocking inlining. RVO is implicit magic that you just pray happens. Const != immutability.

When you write C you have no notion of what the compiler is going to output whatsoever

A lot of these things are available through compiler extensions (so great, now it's not cross-platform), but even still the language is broken. "Expert C Programming" has a really long chapter that goes over all the more confusing subtly problems C has beyond just arrays being pointers-but-not-really.

I have to use C pretty regularly and all I can think is "God.. why hasn't anyone made this better yet"

<comment><USER13> 'C' is quite sufficient for micros and drivers. Micros are supposed to be small. Python's catching on with the kids for systems programming because of Arduino. Drivers are ... well, _drivers_. If you write 'C', you _have to look at the assembly_.

And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?

I really am sorry you have to use it, but there are rather large populations of people who go completely untroubled with it.

<comment><USER5> "And adding inline assembler to manage the hardware - caching, that sort of thing - is just how it's done. Maybe it's possible to make a library ( or a bunch of #defines ) that manages this for you?"

The current ones might be like C on that part, might do something different. I haven't evaluated that. Here's a few:

[http://www.astrobe.com/Oberon.htm](http://www.astrobe.com/Oberon.htm)

[http://www.mikroe.com/mikropascal/#](http://www.mikroe.com/mikropascal/#)

[http://www.mikroe.com/mikrobasic/](http://www.mikroe.com/mikrobasic/)

<comment><USER13> Why is it we're not all using Oberon again? :) Ah, I remember having meetings about things like that... now _that_ was inertia.

SFAIK, ( meaning I don't really ) the various "Mikro" probably do the same thing that the native toolsets for , say PIC, do and simply add default, built-in symbols for bits in control registers and things like turning interrupts off/on. That keeps the amount of assembly further down.

I feel confident in saying that because they'd want to make defection from the default say, AVR compiler chain as painless as possible.

And of course, Linux drivers/ioctl() help a lot with bringing kernel mode things into user space. Using assembler in a driver is just one of those things we find acceptance with.

</comment></comment></comment></comment></comment><comment><USER14> ... as if all development of C stopped with the first ANSI standard?

C99 and C11 are great languages. VLAs, anonymous structs, variable initializers, atomics... they're not the C of the 80s and 90s. They still have the usual warts but the tooling is great and support is coming along for the newest features to most platforms.

While the spirit of, "trust the programmer," might have been a historical accident there is some merit for its usefulness. Our chief problem as programmers is managing data: taking some source inputs, performing a transformation, and sending the output somewhere. That's true of video games, web applications, embedded sensors, etc. As a high-level language, C is one of the few that gives the programmer some control over how memory is mapped to the target platform and allows them to build the appropriate abstractions on that hardware.

It's also a loaded weapon... humans make mistakes and inevitably those mistakes make it into our programs. When working in a language like C one must conduct ones self accordingly.

I'm a fan of FP and ML-style languages. I'm looking forward to a day when we can have our cake and eat it too. It'd be nice to be able to define how memory should be handled for a particular application at the granularity of the target platform while still getting the safety guarantees.

I like where Blow is going with his Jai language. It'd be neat to see more research in this area.

<comment><USER15> > C99 and C11 are great languages.

I think the amount of undefined behavior in C--and that undefined behavior is necessary to compensate for its design mistakes (e.g. signed overflow)--disqualifies it from being a "great language". Empirically, virtually every single large C program in existence depends on undefined behavior to continue working. And that UB is very difficult to spot [1].

> It'd be nice to be able to define how memory should be handled for a > particular application at the granularity of the target platform while still > getting the safety guarantees.

> I like where Blow is going with his Jai language. It'd be neat to see more > research in this area.

You said that you wanted safety guarantees, but Jai is explicitly not about safety guarantees. In fact, being memory unsafe is one of the key design criteria behind the language. That's what differentiates it from for example Rust.

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

<comment><USER16> > I think the amount of undefined behavior in C--and that undefined behavior > is necessary to compensate for its design mistakes (e.g. signed > overflow)--disqualifies it from being a "great language".

The undefined behavior is there primarily to account for the variation in platforms. Higher-level languages avoid this by hiding it in a platform- specific compiler or VM, which in turn limits the number of platforms the code can actually be run on.

> Empirically, virtually every single large C program in existence depends on > undefined behavior to continue working.

Citation needed. I get that undefined behavior is hard to spot, but having spent years writing cross-platform C I cannot accept that every large program depends on it without some evidence.

<comment><USER15> > The undefined behavior is there primarily to account for the variation in > platforms. Higher-level languages avoid this by hiding it in a platform- > specific compiler or VM, which in turn limits the number of platforms the > code can actually be run on.

It may have started this way in the committee (though that isn't true for e.g. type based alias rules), but nowadays it's depended on for performance. You lose a lot of ability to reason about loop trip count if signed overflow is defined, for example.

> Citation needed. I get that undefined behavior is hard to spot, but having > spent years writing cross-platform C I cannot accept that every large > program depends on it without some evidence.

The probability that a program depends on any of (nonexhaustive list) (a) inspecting the value of a dangling pointer; (b) taking the offset from NULL; (c) type-punning through a union; (d) type-punning through any type other than char; (e) signed overflow; (f) order of operations between sequence points quickly approaches 1.

Here's a very interesting survey investigating this: [https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-survey- disc...](https://www.cl.cam.ac.uk/~pes20/cerberus/notes50-survey- discussion.html)

<comment><USER16> > It may have started this way in the committee (though that isn't true for > e.g. type based alias rules), but nowadays it's depended on for performance. > You lose a lot of ability to reason about loop trip count if signed overflow > is defined, for example.

I agree it is depended on in many cases, and should not be. That is on the _programmers_ though, not the language designers. The behavior does not exist to cover deficiencies in the _language_ but those of its _users_.

> The probability that a program depends on any of (nonexhaustive list) (a) > inspecting the value of a dangling pointer; (b) taking the offset from NULL; > (c) type-punning through a union; (d) type-punning through any type other > than char; (e) signed overflow; (f) order of operations between sequence > points quickly approaches 1.

Just on your short list I can tell you the probably of any of our C code depending on that approached zero:

> inspecting the value of a dangling pointer

Our code was malloc once, free never. Dangling pointers were by definition impossible.

> taking the offset from NULL > type-punning through a union > type-punning > through any type other than char > signed overflow > order of operations > between sequence points

Our coding standards covered all of those, so their existence would be a code review failure.

We weren't specifically writing to MISRA C, but I will wager that your statement is not accurate for any project that follows it or any similar standard. Yes, it is a lot of work that you don't need to do with a more controlled and less flexible language. I'm not going to challenge that. I'm just challenging the idea that nobody is writing C that avoids undefined behavior.

<comment><USER17> > Our code was malloc once, free never. Dangling pointers were by definition > impossible.

Dangling pointers can arise in other ways: use an uninitialized pointer variable, take the wrong offset from an otherwise valid pointer, etc.

<comment><USER16> Those are indeterminate values but they aren't dangling pointers. Dangling pointers are specifically references to an object that has been freed.

Plus, the cases you highlighted are programming errors, not reliance on undefined behavior.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> The author snorts at aspects of C that led to its commonplace usage.

> 9\. New design goal: trim out anything hard to compile from CPL. Naturally > eliminates most features for robust and maintainable programming.

Naturally? If those features are hard to compile, then they are hard to reason about; the author begs the question in their statement, but I am not convinced by their conclusion. There's a tendency for things which are hard to reason about to be difficult to port to other systems; it is a complexity issue, and the complexity of a behaviour influences how it can be re-implemented easily or swiftly by others.

> 11\. The result of these was BCPL [5]: a typeless, word-oriented language > with few keywords and unrestricted use of memory. Created philosophy of "the > programmer is in charge and gets no help." Compiler was easy to write on > Most Godawful Computer on Earth. Ran fast on it, too.

Great!

Sounds like BCPL was an excellent tool for their use case, and in providing power with a low difficulty for implementation, it would be easy for others to enjoy its benefits.

> 14\. [...] Stripped out or changed most features benefiting safety/security, > maintenance, and consistency.

Because they were unnecessary. Don't over-engineer your products, or you'll end up with a product that fails in the market; like MULTICS. It's like they learned a thing or two from their past ventures.

My Conclusion: C and Unix succeeded because they were simple to re-implement and/or port. Other, more complex systems were too hard or near-impossible to re-implement and/or port. At a time when good, cheap software was in-demand but scarce the pair were well-positioned to sweep the market, and so they did. Unix may have failed to reach the desktop, but C made it there; because it was easy to implement, had a small foot print, and produced fast code.

It's not like C and Unix stopped development, either. Let's not ignore the last 30 years, now.

<comment><USER4> _Don 't over-engineer your products, or you'll end up with a product that fails in the market; like MULTICS._

While it might have failed in the long term anyway, Multics didn't fail because of market reasons. It failed because first, Honeywell was incompetent at developing serious hardware, e.g. officially blaming the failure of the first (and only, I guess) clean slate Multics CPU project on the decision to microcode the machine. Something which IBM had previously used in the System/360 to dominate the market....

That caused more and more problems as its async CPUs fell further and further behind, although this was still in the discrete logic days, and you could easily use up to 6 in a configuration, and more with a kludge. But it was still selling well, especially in France, where Bull seriously pushed it.

Then it was deliberately killed off due to internal politics, it seems that trying to smash together three computer companies, Honeywell's original stuff, GE's including Multics, and SDS -> Xerox -> Honeywell, creates a situation where killing off rival systems makes sense to political winners who just might not be technological winners.

That Multics was doomed by all this was self-evident to me in the 1979, one reason I never spent any serious time on it.

<comment><USER5> Interesting. I didn't hear that angle before. So, you don't think cost of like $7 million for probably less performance wasn't going to end it? Far as rivals part, that same thing happened once HP had both NonStop and OpenVMS. One had to go. Whereas Unisys did it on purpose when it acquired CTOS, a distributed mainframe. They weren't taking any chances on that one haha.

<comment><USER4> It all depends on what you want to do with it. Crunch numbers? No way after some point. Prepare the Air Force's annual budget submission without information leaking? A real example of a perfect fit. Or provide the IT for MIT's EECS department? Good fit, until MIT-MULTICS was shut down as part of Honeywell killing Multics and the Cambridge lab which did work on it (I played a role in moving off that).

<comment><USER5> Ok, well that makes sense.

</comment></comment></comment></comment></comment><comment><USER19> I remember reading an answer on Quora by a professional C developer why none of existing newly designed programming languages will ever replace C and to be honest with you, I agree with him.

[https://www.quora.com/Which-language-has-the-brightest- futur...](https://www.quora.com/Which-language-has-the-brightest-future-in- replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Roger-DiPaolo)

<comment><USER20> OTOH C has been replaced in many of its previous application areas, and the process continues. A lot of the software people now write in JS, Python, Clojure, C# or CUDA would have been written in C 20+ years ago.

</comment></comment><comment><USER21> EDIT: I got lost in the comment thread. I was intending to reply to this article: [https://www.quora.com/Which-language-has-the-brightest- futur...](https://www.quora.com/Which-language-has-the-brightest-future-in- replacement-of-C-between-D-Go-and-Rust-And-Why/answer/Roger-DiPaolo)

Do Go, Rust, or D programmers really fantasize about their language replacing C in any other context than their own work? The article setups up a huge strawman of a caricature of a person to start and then uses really rather spurious arguments to take pot-shots at that strawman.

But just some easy ones, right off the bat:

"C is not a language for programmers that need to be babysat"

I think the number of buffer overflow exploits that we have seen in the wild over the years indicates that C programmers really do need to be babysat. If you're starting a project and you say "let's do it in C", the rest of your team needs to be taking a really hard look at you and asking, "and just who do you think you are?"

I have never met anyone who knows how to program in C "correctly", because those that have opinions on how it's done always seem to be at odds with some other cohort that is equally convinced of their own superiority.

<comment><USER13> It's possible to write perfectly correct[1] code in 'C'. It's just that some people can't be bothered, and they can't be bothered because it's somewhat tedious.

[1] not to C.A.R. Tony Hoare levels of "provably correct" , the _other_ sort of correct.

Pre-open source, I _never saw buffer overflows_. When I was dealing with full time, professional 'C' coders, this _didn 't happen_. Because we all talked to each other and taught each other how to _not do that_. It's like any other skill or bundle of habits.

I did see the odd "signed integer going negative" or other integer overflow problem, but that was much more about broken analysis and flawed testing. Yeah, it took a little more time to make sure this was the case, but it was just _required_.

</comment></comment><comment><USER22> I assume the author meant Bjarne Stroustrup for items 20 and 21. It's spelled wrong twice, as Bjourne and Bjourn.

> Conclusion 3: C and UNIX should be avoided where possible because they're > Bad by Design for reasons that stopped applying sometime in the 80's or > early 90's.

What does the author propose instead? Is there a major OS that has a kernel not written in C?

<comment><USER6> Perhaps the IBM operating systems? [https://en.wikipedia.org/wiki/IBM_zEnterprise_System#Operati...](https://en.wikipedia.org/wiki/IBM_zEnterprise_System#Operating_systems) . I can't tell what they are written in. Their heritage extends to before C existed.

It also depends on where your major/minor cutoff is located.

<comment><USER22> Oh true forgot about mainframe things. It also looks like VMS has other languages than C: [https://en.wikipedia.org/wiki/OpenVMS](https://en.wikipedia.org/wiki/OpenVMS)

I don't really know where the major/minor cutoff is myself. :)

Pretty much every OS I can think of is in C - Windows, *nix, RTEMS, INTEGRITY, VxWorks

<comment><USER5> Remember that a few of those RTOS's, although OS itself is C, have runtimes for Ada and Java that apparently sold well enough they continue to be updated. Only RTOS I know still done in Ada is MaRTE OS:

[http://marte.unican.es/](http://marte.unican.es/)

Well, Muen is done in SPARK but it's a separation kernel rather than full OS:

[https://muen.sk/#_features](https://muen.sk/#_features)

That it was integrated into GenodeOS framework shows one could build a system around it but it's not quite one itself. There's also the JavaCard OS's for low-level stuff and even Java CPU's on market.

</comment></comment></comment></comment><comment><USER23> The conclusions do not follow from the facts presented

</comment><comment><USER5> @ Tomte

Thanks for posting it as the comments have valuable feedback. I was holding off on responses until it dropped off the front page to let the discussions happen unimpeded. I can already see ways to make the case more clear. What I haven't seen is any contradictory evidence supplied with citations about (a) why C's justifications _then_ no longer apply outside maybe embedded or (b) why it was better a design level than others. A few, good opinions, though. A few comments also have some misinformation on C the article itself addresses despite citations in article... from inventors of BCPL and C... directly contradicting their claims. That's the psychological effect I mention where cause and effect being so far separated in history that affected people not knowing bad causes (or no longer applicable ones) start inventing better, false causes to reinforce their choice of language or faith in its design process.

All in all, I've enjoyed reading the feedback on my ranty summary of that Vimeo vid I did in half an hour or so after doing a C debate. I did condense hours of watching/reading into something digestible but presentation is still shit in a number of ways. Many of points survived with others needing to be improved or replaced to make case clearer. Will do in near future. :)

</comment><comment><USER24> In a world that is overflowing with competing and incompatible operating systems, it's the most portable and fast language that wins over the hearts of those writing software.

<comment><USER5> The _OS_ won due to a number of factors. The language came with it. Then, as the OS spread, the compilers for its source language spread. Then that language was everywhere. With that OS and language everywhere, esp on cheap machines, ecosystem effect kicks in from there where people start building on, using, or targeting it. Most portable and fast language isn't why it succeeded as UNIX could've been built with alternatives. UNIX itself was the killer app that caused C to flourish.

</comment></comment><comment><USER25> This makes a whol lot of good points. C is really not suited for most modern applications, and some of its design choices are questionable (to say the least).

On the other hand: In my opinion, C is a good language to show beginning programmers how memory management is done. Basically, it could be a third learned language, after a scrip language (like python) and an OOP language (Java or C++).

<comment><USER6> It's hard to figure out which are the good points and which are hyperbole. "EDSAC was the second electronic digital stored-program computer to go into regular service" and with "the world's first assembler" dating from 1949, says the Wikipedia reference. As such, many languages can be traced back to that "Most Godawful Computer on Earth (TM)".

Or, "4\. ALGOL60 [4] had many nice features of languages today but was too theoretical: only existed on paper." Yet its reference 4, at [https://en.wikipedia.org/wiki/ALGOL_60#ALGOL_60_implementati...](https://en.wikipedia.org/wiki/ALGOL_60#ALGOL_60_implementations_timeline) , lists a number of ALGOL60 implementations even in the 1960s.

<comment><USER26> Algol60 could never be taken seriously as a mainstream language, lacking Algol-like syntax.

<comment><USER27> Algol60 lacked _Algol-like_ syntax?

In one sense, that's almost tautologically impossible. I presume you mean "like the _other_ Algols", which makes it a non-absurd statement, but... could you expand or clarify what you mean here?

<comment><USER6> I believe it's a joke. Gold isn't a _gold-like_ substance because it is gold. Algol isn't an _Algol-like_ language because it's Algol.

If so, I don't believe it's a good joke.

<comment><USER26> It's a joke, but not the one you thought.

The joke is that the syntax of Algol didn't actually look all that much like what people mean when they say "Algol-like syntax". No curly braces anywhere to be seen.

<comment><USER6> As my introduction to Algol-like languages was through Pascal, the joke completely passed me by.

<comment><USER26> I could see that putting you in a place where encountering people misusing "Algol-like" to mean C-like, when trying to distinguish from something more like Algol, would be extra noticeable and annoying.

Likely you have just been lucky :)

<comment><USER6> I hang around computational chemists. They wouldn't say "Algol-like" in the first place. So, double lucky!

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER27> C is horrible but Algol60, CPL, and Algol68 were wonderful? Um... sure. (Backs away slowly...)

This reeks of ideological blindness, of having reached a conclusion and then throwing mud to try to support it, no matter how biased a twist on the facts it takes.

</comment><comment><USER28> Calling UNIX Bad by Design... oh my gosh!

<comment><USER29> If you thought that was entertaining, you'll get a kick out of reading the old UNIX Hater's Handbook.

[http://www.vbcf.ac.at/fileadmin/user_upload/BioComp/training...](http://www.vbcf.ac.at/fileadmin/user_upload/BioComp/training/unix_haters_handbook.pdf)

In particular, at least check out Page 36, showing an articulately hand-drawn Dennis Ritchie, in stoic defiance, blowing raspberries at UNIX critics through his thick-rimmed glasses. It's by far the high point of the book.

<comment><USER30> The nice part about the Unix Haters book is that the authors were actually familiar with their subject material :-).

<comment><USER5> The funny thing about gcr's comment is that I posted ESR's review of UNIX Hater's Handbook here before. He agreed with a good chunk of it while noting other stuff changed or was ranting. As for your comment, I came to C after using alternative, system languages that compiled faster, crashed less, and ran fast. After I figured out basics of C & read secure coding books, I said "F#$@ this!" It was an unnecessary and horrible development experience. So, I coded up a 4GL that let me develop in industrial BASIC that compiled to C apps with checks in to use their compilers and libraries. Macro'd out boilerplate. People thought my "C code" was fast and thorough but I never wrote in that garbage language except prototyping the tool. (Long gone so don't ask.) My application areas were OS-level stuff, games, AI, networked apps, and GUI apps. Shows how easy it would've been to ditch given I sucked at compiler design.

Eventually, I discovered how it was created, that most proponents claims weren't accurate depiction, and did this write-up. Glad you enjoyed that I kept it close to subject material from its inventors. Meanwhile, the C inventors went onto design, with Pike's help, a better language that solves most of C's problems while maintaining a Wirth-like level of safety and development. Pick up Go language if you want to know what that experience is like. Personally, I'm more for a subset of Modula-3 with Rust's dynamic safety, SPARK Ada's extensions for correctness, and macro's for DSL, productivity benefits. Or efficient functional one with similar properties.

</comment></comment></comment></comment><comment><USER31> Good overview. Wrong conclusions.

</comment><comment><USER32> I think a large problem with this is that people unreasonably idealize the features of ALGOL 60 and many other "Perfect Systems Languages"

The issue is that there are not any major open source projects to examine that use these languages to see how they actually work in the wild. For example, writing a Java codebase with nothing other then the standard library you can do some very nice design patterns. You can come up with some very clean and concise code and everything can be perfect. Then, when you go to integrate with someone else's code (see Spring) you notice that everything becomes a mess since they are using some crazy things that make it very difficult to integrate with it.

Due to this it's impossible to say how well another language would behave in the wild since I don't think anyone can predict how well the language will be used to it's extent.

That being said, I think C succeeded because it was SIMPLE. Not only for the compiler, but I can teach pretty much anyone how to understand C in most likely a few days to a week. It's very simple and very little you need to know to understand how to start writing your programs.

On the other hand, ALGOL is MASSIVE. There are 106 reserved identifiers in the language according to wikipedia and I don't think I could ever remember what every one of them did.

Currently C has about 32 key words and I can tell you in full detail what every one of them means except union as I don't work much with C.

This is good for the beginning programmer since it shortens the time they need to hit the books and helps them jump strait into writing.

Something that's good for the advanced programmer, in my opinion, is the use of braces and not words.

I know this is kind of controversial but I do honestly think that a code should be easily segmented by the eye not readable.

Begin and End only help so much and by so much I mean not at all. Words should not be syntax in my opinion. Seeing { } is less to look at and understand then seing Begin and End.

This sample phenomenon can be looked at from the recent Linux 1000 patches debacle.

Linus said he didn't want to replace unix file permission numbers with the symbolic values. Why? Because it's much much faster for someone to see the numbers and know what's going on then to have to read a bunch of text. It's much quicker in parsing.

That's where the breakdown comes in these discussions. People will throw "You've never used these, how do you know yours is faster."

While that's true that doesn't really present a good argument for changing everything.

I also hate needing to type := for assignment. It makes no sense. Fixing the beginner issue of missing the second equal sign in an if statement has a much simpler fix. Use some kind of IDE/Editor with a linter. You'll not have this problem.

<comment><USER27> > I can teach pretty much anyone how to understand C in most likely a few days > to a week.

I learned C from reading K&R over a Thanksgiving weekend, without even a compiler to try it out on. The only thing that confused me was the explanation of argc and argv.

<comment><USER5> I learned an industrial BASIC in a few hours if you add it all up. Learning how to use it reliably took weeks with safety mostly coming by default. Learning that for large stuff took several months where I learned programming practice. How long do these milestones take for average C developer with what productivity? Note that my Pentium 3 at 400MHz could compile the compiler in a second or two. Fast iterations. :)

Learning C was a different experience entirely. The mental work involved was huge with the level I worked at for _any job_ being micro-managing the machine. It's only simple on the surface. The job is much harder than a BASIC, Oberon, or whatever with selective use of unsafe features.

<comment><USER27> I said that I understood the language after reading K&R. The language is simple. Using it safely? Not so simple. I didn't claim that it was.

On the other hand, I learned BASIC on a TRS-80. Safe? Not with the POKE command being part of the language.

<comment><USER5> Ok. Fair enough haha.</comment></comment></comment></comment></comment>


Blackout your Drupal site on January 18th (inspired by Wordpress plugin) - <AUTHOR> https://github.com/mcantelon/drupal-sopa-blackout Whipped this up quickly after seeing the Wordpress plugin... let me know if you run into any issues. I made this/tested for Drupal 6, not sure if it'll work for Drupal 7. <comment><USER2> all 6 drupal users can black their sites out now!</comment>


Box2DJS - Physics Engine for JavaScript - <AUTHOR> http://box2d-js.sourceforge.net/ <comment><USER2> <http://code.google.com/p/box2dweb/> is more up to date and the developer is still actively maintaining it. Like Box2DJS, it is mostly automatically converted from the ActionScript port of Box2D (though Box2DJS, again, is based on an outdated version).

<comment><USER3> Ahhh I just did some work this week using the older codebase. Any idea how much changed between these two versions?

</comment></comment><comment><USER4> I especially like the fact that it's generated automatically from Box2D for Flash!</comment>


Photo Editor – A simple online photo editing application - <AUTHOR> https://github.com/fengyuanchen/photo-editor <comment><USER3> My first observation was that it took me a moment to work out how to confirm the crop. The confirm button is unlabelled and in the top right of the screen - a place I would generally expect 'global' actions rather than an action crucial to my immediate task.

EDIT

Second observation - even more confused. I hadn't accepted the crop - <USER2> I'd entered a new mode with no more editing possible - only the four unlabelled icons in the top right (you get the impression I really hate unlabelled icons? Google 'mystery meat'...)

So I'm trying to wrap my head around the conceptual model. I can do multiple things to my image - but the crop doesn't give me a preview until I accept all the edits. So how am I meant to crop then flip or some other combination?

<comment><USER4> I did the same thing. I'd suggest that a double-tap/click on the cropped area should confirm the crop.. At least that was my first instinct.

<comment><AUTHOR> Confirm the cropping by double-click is supported now. Thanks.

</comment></comment></comment><comment><USER5> Looks pretty good. Have you considered turning this into a Chrome extension?

I've not found a simple photo editor extension that I can use within Chrome. Ideally I'd just like to right click on photos, do simple crop/resize/quality/colour conversions and have the results available for insertion into gmail attachments or form uploads (via a temp URL perhaps?).

This would replace my current workflow...often I find myself receiving a set of images in gmail, downloading them, performing trivial manipulation with Windows photo editor or paintbrush, saving the results with sensible encoding/quality (some ppl forward me bitmaps...) then re-uploading the results.

<comment><USER6> Is some thing like Polarr online too complex for you, it also has a chrome app (works offline) [https://www.polarr.co/](https://www.polarr.co/)

Disclaimer: Founder of Polarr

<comment><USER5> Hi, I have not tried Polarr before.

It looks great, and i'll probably give it a go. However it doesnt improve my workflow - I still have to download my photos from Gmail (or random websites or whatever) and open them in Polarr.

Recall I'm looking for integration with a browser. If it was a Chrome _extension_ , and I could right click on any image, on any webpage, and select 'Open with Polarr', that would be a great start.</comment></comment></comment>


What Universal Human Experiences Are You Missing Without Realizing It? - <AUTHOR> https://slatestarcodex.com/2014/03/17/what-universal-human-experiences-are-you-missing-without-realizing-it <comment><USER2> I realized about 30 years ago that for me, it's food (much like the conversation in the article).

I mean, there is food that I dislike, and food that I don't dislike, but it took a long time to realize that other people genuinely, deeply, love and enjoy food in a way that I don't, and will probably never, understand. Food, for me, is just a thing I need to eat to continue living.

I didn't even realize that I was unusual about this for a long time. I thought I was pretty normal!</comment>


Don't waste time on problem that haven't occurred yet; focus on the best solution to the main problem - <AUTHOR>

When working on a project, don't solve problem that haven't arrived yet. It doesn't mean we don't know them, but we need to focus on the main problem first. The youtube guys didn't think of copyright videos before they started youtube. They were set to solve the web video sharing problem, and that's what they did. Stay focus; that's the reason we're working on the project in the first place. We're not working on a prject to look for future problem; we're working on a project to get the best solution to a main problem. <comment><USER2> I have to disagree. There is a main goal, there are implications. We need to solve both of them to deliver good/great product or at least have proper precaution. Every now and then I remind myself about vista problem and how they got class action lawsuit.

</comment><comment><USER3> I completely disagree. It's shoddy and inefficient to wait for a problem to arrive. Imagine if the guys at Google just sat around waiting for their server to kick the bucket before they fixed it; they'd be out of business.

Problems aren't mutually exclusive, I can fix more than one at once. If my server is bust, it doesn't matter if my ISP is cutting me off in a week, but if all it takes is a call to another ISP to get another connection before the deadline then I'm not going to turn 1 week of having a downed server into two weeks with no useable service.

Only solving problems as they arrive is the work of the mediocre, the good fix things before they arrive. By your own example, the YouTube guys -didn't- think of copyrighted videos and they got a $1 billion lawsuit! That isn't a smart thing to allow to happen, if precident gets set against YouTube in one single case, they're broke and gone because they didn't think ahead.

<comment><AUTHOR> Obviously you're missing the point. In google's case a server problem is a main problem. It's a software company. I didn't say only solve problems as they arrive. I said don't waste time on problem that haven't occurred yet. What that means is stop making excuses; look for reasons instead. In youtube case, it was still acquired for $1.65 billion. Youtube revolutionize the way people share and watch videos online. That $1 billion lawsuit probably will be dismissed. Worst case scenario, it still won't kill youtube. By the way, name me one succesful company that haven't been sued yet? goole, microsoft recently iphone from apple.. all them. "If you haven't been sued, you haven't made it". The point is start your project now, stop worried about employee health insurance. Deal with problems you have today, don't worry about problems you will have in 5-10 years. Stop making excuses; find reasons.

<comment><USER3> I think the point is to be a successful company and not get sued.

Getting sued is patently moronic, and being proud of it is more so. Wal-Mart is being sued for 11 billion (and growing), and they make 11 billion profit. If Wal-Mart doesn't get profit for a year it will have to sacrifice 11 billion of assets and put every company around it into a better position. Thus shareholder/stock decrease and a vast loss of capital meaning it'll be harder to recover from.

Wal-Mart can suffer it, probably with some dire consiquences, but it won't disappear, now YouTube:

So far YouTube isn't worth shit. It is yet to turn a profit, and a $1 billion lawsuit means that around 60% of YouTube's capital has to go. Capital = Equipment. YouTube is gone if it loses 60% of itself, not to mention there'll likely be multiple and far larger suits on the way from Sony, Disney, News Corporation and everyone else who wants a chunk and all of those three have a much bigger grivance than $1 billion; precedent means a Judge basically stamps these approved. I'd say easily it would amount to $20 billion as Sony owns Colombia, Tristar and MGM as well as Sony Pictures; that's easily $8 billion right there.

Now you do the math on that, how can youtube even exist when it's about -$19 billion? I'm serious, where does your belief come from that worst case youtube still won't be killed. It'll be a 404 if it loses.

Whilst merely thinking about the future will get you nowhere, never thinking about the future will jeopordize your company to no end. YouTube should have thought ahead, Wal-Mart shouldn't have been sexist pigs... and perhaps you should worry your ass off about Employee Health Insurance, cause I bet Wal- Mart didn't expect a Class Action worth an entire years profit. I don't think you want to lose an entire years profit either, especially when it's your ownly take home money.

So I'm serious, and I'm not missing any point. Think or your company won't last long. The creators of YouTube likely got lucky... if they're not still with the company. And if they are with the company, well Karma is a bitch now isn't it.

<comment><AUTHOR> If you're going to solve a problem that's not an issue yet, you'll never create anything of value. You'll just be in a looping of solving problem that doesn't exist. Because of youtube, the video copyright law will change. We start startups to make the world a better place: change laws, change the way we do things; not staying on the same corrupted path we're on. When goog started, people were concern on how goog could make sure not to index webpages without webmasters permission. That was an issue; but goog didn't think it was important. Now webmasters pays $1000 of dollars for their link to be listed on goog first page search. Sometimes an issue appears because the mass population hasn't adopt to it yet. I truly believe ones can break any law or disregard a problem as long as he/she has a purpose reason. If you don't agree, ask the US commander-in-chief.

</comment></comment></comment></comment><comment><USER4> In general, I agree. But was there a huge demand for online video before YouTube launched? They were smart because they made it super simple, but they were a chicken chasing an egg in the beginning.

</comment><comment><USER5> Thanks for the tip bud.</comment>