The document discusses the limitations and frustrations of current programming languages and tools, proposing a new hybrid language called ooc aimed at improving software development experiences. It emphasizes modular design, ease of use, and innovative features like garbage collection and generic programming, while critiquing existing approaches to software architecture. The document concludes with a vision for ongoing improvements and the broader community engagement around the ooc language.

1. ooc A hybrid language experiment

2. Why? Software sucks It's unreliable

3. It's slow

4. It's too hard to develop

5. It's not modular enough

6. [insert rant here] « The quality of a piece of software is inversely proportional to its popularity. » — Buchheit's law

7. Why? The fate of popular software

8. Why? Languages suck void (* signal ( int , void (* fp )( int )))( int );

9. Why? Languages suck void (* signal ( int , void (* fp )( int )))( int ); signal : Func ( Int , Func ( Int )) -> Func ( Int ) ✔ ✘

10. Why? Tools suck small.cpp(17) : error C2664: 'class std::_Tree<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >const ,int>,struct std::multimap<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,int,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> >::_Kfn,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> > ::iterator __thiscall std::multimap<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,int,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<int> >::insert(const struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int> &)' : cannot convert parameter 1 from 'const int' to 'const struct std::pair<class std ::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,int> &' Reason: cannot convert from 'const int' to 'const struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> const ,int>' No constructor could take the source type, or constructor overload resolution was ambiguous

11. Why? Tools suck GNU autoconf, automake, autoreconf – masochism

12. GNU ld – the kitchen sink of linkers

13. GNU make – the brainless servant Bad workers blame the tool What if good workers do too?

14. Break with tradition

15. Why? School assignment in C – laziness. 4 months later – ooc 0.1

16. « Version 1 Sucks, But Ship It Anyway » – J. Atwood Finding a purpose To remove obstacles

17. To encourage experimentation

18. To minimize frustration

19. What? Classes, abstract, single inheritance, virtual by default

20. Garbage collection (Boehm, opt-out)

21. Covers, function overloading

22. Partial type inference, more type-checking

23. Arrays, pointers, manual memory management

24. Generic functions, generic classes, collections

25. Interfaces, operator overloading, properties

26. Closures, first-class functions, map/filter/reduce

27. What? I was gonna describe the syntax here

28. But we're short on schedule so I'll just sum it up:

29. « ooc syntax is Java without bullshit » - Anonymous

30. I'm sorry if you were offended.

31. Java offends me too.

32. Design principles Build upon, extend, divide and conquer

33. Re-use what makes sense, rewrite the rest as we go

34. JDK – an example of how NOT to do modularity

35. SDK – all you need to get started, easy to swap out

36. Dependency management made easy

37. Making it easy to use libs encourages good design

38. Acronym fair DRY

39. KISS

40. IYFF

41. YAGNI

42. RTFM RTFC

43. TMTOWTDI

44. Paradigm City Procedural println(&quot;Is i+=1 deterministic?&quot;)

45. Paradigm City Object-oriented Window new(&quot;Vista&quot;). add( Button new(&quot;Buy&quot;). connect(&quot;clicked&quot;, || &quot;Seriously?&quot; println() ) ). showAll()

46. Paradigm City Generic programming Cell: class <T> { data: T next: This<T> init: func (=data) {} } c := Cell new(42)

47. Paradigm City Functional (1..100) map(|x| x*x) reduce(|a, b| a+b)

48. Paradigm City Preemptive multi-threading mutex := Mutex new() Thread new(|| mutex lock() // prove Fermat's last theorem mutex unlock() ) start()

49. Paradigm City Communicating Sequential Processes chan := make(Int) go(|| chan << question answer := ! chan ) 24h for a basic implementation using libcoroutine 80'000 concurrent coroutines = easy, more with tweaks

50. Paradigm City ...is pretty much a nice walk with ooc

51. Provide the necessary building blocks

52. Don't enforce the « one true way »

53. Politics != Technology

54. High-level low-level language.

55. Generating C – the perks

56. Generating C – the perks throw old VMExcuse ( &quot;I wasn't ready!&quot; ); if name == &quot;__main__&quot; : dont_hold_your_breath ()

57. Generating C – the perks GCC (Gnu Compiler Collection), TI-GCC, mingw32

58. TCC (TinyCC)

59. ICC (Intel C++ Compiler)

60. Clang (LLVM)

61. PCC (Portable C compiler - with tweaks)

62. No MSVC (yet?) - they're too busy with C++0x

63. ...although in theory it wouldn't be that hard.

64. Generating C – the perks Did you know that GCC -O2 did TCO?

65. Turn segfault into infinite loops.

66. Protip: use -O0 (the default) when debugging

67. ooc - the platform Self-hosting

68. Without a doubt the best way to generate C

69. A real module system. Partial recompilation.

70. The compiler as a library

71. C from ooc is easy

72. ooc from C is easy ( #define OOC_FROM_C )

73. ooc from Python is dead easy!

74. ooc from X = reading JSON compiler output

75. ooc – the tools Good compiler errors

76. Valgrind, GDB

77. Alleyoop, Nemiver (GTK frontends for the above)

78. Callgrind, Kcachegrind, gprof

79. (Pseudo-)REPL, IRC bot

80. Emacs mode – flymake, tooltips with compiler errors

81. Lots of C bindings

82. Why use ooc? Because you have a llama syntax fetish

83. As a better C/C++

84. As a better Java with no VM

85. Because of the tools

86. Because of the community

87. You want to be part of the adventure

88. What's next? Optimizations Generic calls inlining – expect huge speedups

89. (Please, Mr. Shapiro, don't burst into flames)

90. Escape analysis, stack-allocation, annotations An alternative to exceptions

91. Typesystem improvements Mixins

92. Typestate? Meta-programming, compile-time execution

93. That's all, folks! Web http://ooc-lang.org IRC #ooc-lang on Freenode Twitter @nddrylliog Mail [email_address]