ooc - A hybrid language experiment
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

ooc - A hybrid language experiment

on

  • 1,170 views

An introduction to the motivation behind the ooc project. ...

An introduction to the motivation behind the ooc project.

In a nutshell: software sucks, tools sucks, languages sucks - examples of what not to do. How ooc allows you to do pretty much aything with a few building blocks. An overview of the advantages/strong points of ooc.

Statistics

Views

Total Views
1,170
Views on SlideShare
1,145
Embed Views
25

Actions

Likes
1
Downloads
7
Comments
0

1 Embed 25

http://www.oscon.com 25

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

ooc - A hybrid language experiment Presentation Transcript

  • 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]